Simplify the onboarding process for new contributors by using DDEV

I'm not sure it's our place as just another contrib module to be maintaining documentation and make files to assist users in setting up a Drupal development environment: this places a burden on the maintainers to keep everything up-to-date for a Drupal development environment as well as forcing them to make decisions that may not suit all devs.

For example: the makefile sets up DDEV to use PHP 8.1, which is not the PHP version recommended by Drupal core - the maintainers of *this* module have made the decision to test and develop against 8.1 and higher for their own reasons, but does that make sense for all developers? Should every contrib module be providing their own makefile for a DDEV environment that is tweaked to developer for their modules?

I feel like this is an issue that belongs against Drupal Core, where it would be easier to maintain against the latest version(s) of Drupal.

Hello @mrdalesmith, the goal of this MR wasn’t to make DDEV usage mandatory. Rather, it aims to streamline the use of a tool already recommended for local development in the current module's documentation. Regarding the PHP version, we can certainly make it configurable via an .env file or a similar method.

I was thinking more that - whilst DDEV is recommended by this project - forcing the maintainers to teach people how to set it up feels out of scope for this project and is more suited to something Drupal core should do (if indeed it wants to). Not a maintainer, so this is only an opinion, not a rejection of the idea. Does feel to me though like an extra burden on the maintainers.

I agree with @mrdalesmith here - we do not specifically want or need people to run DDEV. The reason there exists a helper section on DDEV is for two reasons:

1. It will be the official solution of Starshot/Drupal CMS
2. We have specific Docker/DDEV services documented like Milvus, Unstructured, Ollama, Pinecone etc. and configurations like streaming, that you rarely run in any other use case then using AI. But the documentation part about DDEV assumes that you know how to use DDEV already.

So having a DDEV make file makes little sense, because you would still need knowledge about how you bootstrap and setup the extra services in DDEV, since they are choices of what you need/want.

Does this make sense?

Understood, I've removed the Makefile and updated the ddev.md file to contain links on how to setup DDEV for a Drupal project. I've also required drush as require-dev, which could be useful, and committed a .gitignore file that ignores files generated by DDEV. Keeping this in "Needs review".

I don't think we need to require drush for this project: drush is a Drupal-wide tool and there's nothing in the dev set up of this particular module that requires drush. The set up of DDEV and Drupal is outside the scope of this project, and we shouldn't be tying things in that are useful for general development into this specific module.

Should I also remove the .gitignore then, and only leave the changes to the ddev.md file?

@ademarco - I think the changes to the markdown is enough, its great to link to the general setup if someone wonders what DDEV is.

The .gitignore will just confuse people that might wonder why we build a vendor library in the module and composer dev dependencies should only be needed if/when its needed for gitlab testing reasons or local testing reasons.

Ok, I've force-pushed one single commit with only the changes to ddev.md.

Thanks, merged

Automatically closed - issue fixed for 2 weeks with no activity.