launcher script appends -1 to every project created

if [ "${n}" -gt 0 ]; then
  NAME=${NAME}-$((n + 1))
fi

This looks correct, but I see one issue: if I run the script again by mistake, it will create a new project each time instead of starting the current project. It keeps appending a numeric suffix to the name each time it runs.

With @stasadev's suggestion, I see another issue. If we try to install it inside inner directories of any DDEV project, it will not work as expected. This is because `ddev describe` will return the project from the parent directory instead of the current directory. So, a more reliable approach could be:

# Check if a DDEV project exists in the current directory only
if [ ! -f .ddev/config.yaml ]; then
  NAME=$(basename $PWD)
  # If there is any other DDEV project with the same name, add a numeric suffix
  if ddev describe "${NAME}" >/dev/null 2>&1; then
    NAME="${NAME}-1"
  fi
  # Configure a new project
  ddev config --project-type=drupal11 --docroot=web --php-version=8.3 --ddev-version-constraint=">=1.24.0" --project-name="$NAME"
fi

> With @stasadev's suggestion, I see another issue. If we try to install it inside inner directories of any DDEV project, it will not work as expected. This is because `ddev describe` will return the project from the parent directory instead of the current directory.

I am not sure if this is the right approach to create a DDEV project inside another DDEV project.

By the way, in the next release of DDEV, it will not be possible to configure a DDEV project inside another DDEV project using the command line (`.ddev/config.yaml` still can be created manually) https://github.com/ddev/ddev/pull/6852

Thanks, @stasadev, for highlighting the upcoming change in DDEV!

You're absolutely right—it’s not an ideal approach to create a DDEV project inside another DDEV project. However, since it was allowed previously, I considered that scenario.

I updated my code in the issue summary, which should better handle the edge cases described.

I've discussed the topic with @stasadev via Discord and tested the proposed resolution. with previous proposed resolutions i ran into issues. the initial proposal i sent over had the problem with three folders of drupal-cms the first launched launcher gets drupal-cms as the project name , the second drupal-cms-1 and for the third it refused to set up a project. and the problem with trying to setup a new instances of drupal cms inside the subfolder of an already installed instance of drupal cms ran on DDEV HEAD wasit behaved correctly, by running ddev config (updating the config the project in the parent folder) and then run ddev start (ddev restart in this case strictly speaking), but as i said not apparent to the user.

with the proposed resolution @stasadev posted i was able to create several instances of drupal-cms across my file system, and it properly counts up, i'Ve stopped after drupal-cms-4... the first project was drupal-cms, the second drupal-cms-1.. and when you try to execute the launcher in a directory where its folder is a subfolder of another already registered drupal project the script now just exits and we agreed on providing some context with You're trying to set up a Drupal CMS inside an existing project in $(pwd), refusing to do it. ... that way the user knows what goes wrong and where to look for the parent project by the path that was provided.

thank you! looks good to me. tested another round with the latest changes. created three instances in three different directories which results in drupal-cms, drupal-cms-1, and drupal-cms-2 projects. and when i copied another install inside a subdirectory of one of those three instances i get:

[rkoller@mycomputer][~/zeug/drupal-cms/recipes/drupal-cms]
$> ./launch-drupal-cms.sh 
You're trying to set up a Drupal CMS inside an existing project in /Users/rkoller/zeug/drupal-cms, refusing to do it.

i leave the issue at needs reviews. but from a manual testing perspective this looks good to go and is an improvement.

unassigned @stasadev since the issue is ready for review (but asked him and made sure he isnt still working on anything)

I just tested as follows:

1. I already had these installed: drupal-cms-dev and quant-drupal-cms-1
2. Installed using composer create-project drupal/cms with the old script
3. It created cms-3 which makes sense based on the old logic
4. Installed again using the new script and it created cms which makes sense because it's using an exact name match
5. Installed again and it created cms-1
6. Installed again and it created cms-2
7. Installed again and it created cms-4
8. I deleted cms-2 and installed again and it created cms-2 as expected

So, the logic works, but I'm not sure if the code looks okay.

Actually... this needs work because, when I use a different directory name, then it doesn't work:

macbookpro:testing_drupal_cms kristenpol$ ./launch-drupal-cms.sh
Creating a new DDEV project config in the current directory (.../Sites/quant/another_cms/testing_drupal_cms) 
Once completed, your configuration will be written to .../Sites/quant/another_cms/testing_drupal_cms/.ddev/config.yaml
 
Configuring a 'drupal11' project named 'testing_drupal_cms' with docroot 'web' at '.../Sites/quant/another_cms/testing_drupal_cms/web'.
For full details use 'ddev describe'. 
failed to validate config: testing_drupal_cms is not a valid project name. Please enter a project name in your configuration that will allow for a valid hostname. See https://en.wikipedia.org/wiki/Hostname#Syntax for valid hostname requirements 

We should be able to use a different name.

> when I use a different directory name, then it doesn't work

Thanks, should be fine now.

Changes:
- check for underscores and spaces in the directory name
- early check for DDEV v1.24.0 before doing any action
- remove fragile code that depended on `jq` and `docker`
- replace infinite "while" loop with "for 1 to 1000"

I do have a question here that is a bit meta. Why are we using a complex launcher script that requires all this maintenance, when we can do the exact same thing with `ddev composer create` as with the suggested `composer create-project`? The DDEV-recommended technique in https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal-drupal-cms is to do the `ddev composer create` and it's very easy. I'm baffled why we need a launcher script and a zipball. Or perhaps if we want a launcher script, why doesn't it just do the `ddev composer create` ?

I'm happy to open another issue, but this one could be put aside if we just went with simpler instructions.

The changes look okay but there are some out-of-scope things that should be done in other issues.

@rfay's point is also a good one - we have to find the right balance between making this easy for people and driving ourselves nuts. Given the way things look on new.drupal.org -- where the DDEV instructions are linked from another page -- the value of the launcher script is becoming dubious indeed. This is a product decision, though, and therefore needs to be run by @pameeela.

So, assigning to her and postponing any further action until we've decided if this launcher script is worth it to us.

I'm inclined to agree now that there is dedicated Drupal CMS documentation for DDEV. The existence of this launcher script is (I think) also causing some folks to think that DDEV is the only way to install from the zip.

So probably we need to create a new issue to remove the launcher script in the next release, and coordinate all necessary updates to documentation. As part of this, we should also make it clear that DDEV is a suggestion and not a requirement.

And then we can close this as won't fix.

The launcher was removed in ✨ Replace the launcher script with better documentation Active , so this is not gonna get fixed. :)

stasadev → closed merge request !456