ddev icon indicating copy to clipboard operation
ddev copied to clipboard

ADD `ddev config` should infer/detect PHP version from `composer.json`

Open allanlaal opened this issue 2 years ago • 14 comments

Is there an existing issue for this?

  • [X] I have searched the existing issues

Is your feature request related to a problem?

I init new ddev projects daily. going to edit the .ddev/config.yaml to change the actual php version from 8.0 (current global default I assume?) to whatever I actually need gets old very fast

OR user doesn't init that many ddev projects forgets that PHP version is not inferred from composer.json inits a ddev project and wastes a million hours trying to figure out why everything is broken

Describe your solution

ddev config should search composer.json in cascading order for:

  1. require-dev.php (since we are most likely in dev, since we are using ddev)
  2. require.php
  3. config.platform.php
  4. ddev global default php
  5. current env php version

Describe alternatives

manual labour

Additional context

$ ddev version
 ITEM             VALUE                                   
 DDEV version     v1.21.6                                 
 architecture     amd64                                   
 db               drud/ddev-dbserver-mariadb-10.4:v1.21.5 
 dba              phpmyadmin:5                            
 ddev-ssh-agent   drud/ddev-ssh-agent:v1.21.5             
 docker           20.10.17                                
 docker-compose   v2.15.1                                 
 docker-platform  S4                                      
 mutagen          0.16.0                                  
 os               linux                                   
 router           drud/ddev-router:v1.21.5                
 web              drud/ddev-webserver:v1.21.5        

allanlaal avatar May 11 '23 15:05 allanlaal

Unfortunately, not all projects use composer, and not all composer.json properly suggest the php version, and composer.json is not always in a predictable location.

Why don't you start using ddev config --php-version=<whatever> instead of just ddev config ?

rfay avatar May 11 '23 15:05 rfay

BTW, not sure if this affects you, but most teams check in the .ddev directory, so only the team lead (or someone doing a PR) will change the configuration.

rfay avatar May 11 '23 15:05 rfay

I run lots of random PHP libraries and projects from github, where there is no .ddev directory the PHP version itself differs all the time

allanlaal avatar May 11 '23 16:05 allanlaal

So... ddev config --php-version=what-you-want

rfay avatar May 11 '23 16:05 rfay

I imagine this as an optional param in the config.yaml file, telling DDEV whether it should respect the PHP version defined in composer.json file or not. This may be particularly helpful in teams where not all members are aware of DDEV configuration.

mrneatly avatar May 12 '23 08:05 mrneatly

Some frameworks (Eg. Drupal) do not have PHP declaration in their composer.json. There's movement towards supporting Javascript-based framworks that are not based on PHP (see #4898).

Personally, I configure DDEV once at the start of the project and commit the ./.ddev/config.yml. People that clone the repo will then get the correct version of PHP when using DDEV. If they are using something else (Eg. XAMPP), composer reports any PHP conlicts when trying to resolve the versions via composer.lock.

tyler36 avatar May 12 '23 08:05 tyler36

I don't expect that this would be done any time soon. AFAICT there are lots of ways for you to adapt your workflow.

For example, you could add a pre-start exec-host command that would update the PHP version of the project based on what it finds in composer.json. You could just ddev config --php-version as needed. Lots of other ways too.

I don't think your idea is a bad idea, but I doubt it will make priorities without support from others, but a contribution would be considered. I'm going to close this for now, but others can chime in later and of course we can reopen as needed and discuss more as needed.

rfay avatar May 17 '23 17:05 rfay

NOT completed ddev version v1.22.7

ddev is supposed to be for PHP and it doesn't support its biggest package manager?!

lemme know if you need help with this

also please reopen

allanlaal avatar Feb 12 '24 15:02 allanlaal

I don't expect DDEV to change PHP version based on composer.json, as all projects don't even have a composer.json, and it may not be in the root.

DDEV has extensive support for composer, and you can change the PHP version any time you want, ddev config --php-version=<version>

Remember that for many projects the composer.json does not even exist at the time of project creation.

rfay avatar Feb 12 '24 15:02 rfay

I only want ddev to infer PHP version from composer.json when there is a composer.json in its root dir.

..in addition to ddev's other inferring logic, not instead :)

allanlaal avatar Feb 12 '24 16:02 allanlaal

I understand that you want this. Have you considered creating a PR with appropriate (and very significant) tests, or having your organization support DDEV at a substantial level?

DDEV only does static PHP version inference (by project type). Otherwise it uses the default or what's configured.

rfay avatar Feb 12 '24 16:02 rfay

please reopen :)

allanlaal avatar Feb 12 '24 16:02 allanlaal

Hi @allanlaal,

It's a good idea, reopened it.

It reminds me how PhpStorm uses composer.json to determine what PHP features are available or not.

I only want ddev to infer PHP version from composer.json when there is a composer.json in its root dir.

No need to limit this to the project root. We always know the folder used for the composer inside the container, this new check should use the specified directory composer_root.

This feature should also respect disable_settings_management.

And, of course, we need a validation for the parsed PHP version.

Happy that you are interested in this!

stasadev avatar Feb 12 '24 17:02 stasadev

Somebody else was asking about a feature like this the other day.

rfay avatar Feb 23 '24 15:02 rfay