build: always use /usr/local/bin/composer, fixes #6771#6772
Conversation
|
Download the artifacts for this pull request:
See Testing a PR. |
|
Let's add to doc here what people need to do if they do want to use the composer-installed composer. |
rfay
left a comment
There was a problem hiding this comment.
This seems correct. There's still going to be a little confusion, but I think it's ok.
The weird thing I encountered is this:
ddev exec which composer gets vendor/bin
ddev exec composer --version gets /usr/local/bin
Not sure how that can happen. I guess because which is a bash built-in.
ddev composer is always getting the right version.
Docs look good.
| Tty: isatty.IsTerminal(os.Stdin.Fd()), | ||
| Env: env, | ||
| // Prevent Composer from debugging when Xdebug is enabled | ||
| Env: []string{"XDEBUG_MODE=off"}, |
There was a problem hiding this comment.
Is this related to the revert here? Or just a good idea? I thought it was in here before.
There was a problem hiding this comment.
I reverted the Env to its original state.
The Issue
vendor/bin/composerdoesn't seem to be what we want, it's confusing and people can't override it withddev config --composer-version=<version>How This PR Solves The Issue
Reverts behavior to use
/usr/local/bin/composer.Removes
vendor/bin/composerfrom$PATHinside the container withEXECIGNOREhttps://www.gnu.org/software/bash/manual/html_node/Bash-Variables.htmlThis way it will use
/usr/local/bin/composerinstead of/var/www/html/vendor/bin/composerwithddev ssh.(Prior to this PR,
ddev ssh&&composer -Vhad always preferredvendor/bin/composerno matter what.)vendor/bin/composercan still be called directly.Manual Testing Instructions
https://ddev--6772.org.readthedocs.build/en/6772/users/configuration/config/#composer_version
The only downside is that
EXECIGNOREhas no effect onwhich, so it will still show/var/www/html/vendor/bin/composer, but will actually use/usr/local/bin/composer, so we will have consistency between inside and outside:Automated Testing Overview
Release/Deployment Notes