Cannot run Composer binaries without path anymore

[mbrodala]

Expected Behavior

Assuming a Compose service app using this Docker image and phpstan/phpstan is installed via Composer, running its binary vendor/bin/phpstan should work without the path prefix vendor/bin:

± docker compose exec app phpstan
Note: Using configuration file /var/www/html/phpstan.neon.
 453/453 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%


                                                                                                                        
 [OK] No errors                                                                                                         
                                                                                                                        

Current Behavior

Trying to run a Composer binary without path fails:

± docker compose exec app phpstan
OCI runtime exec failed: exec failed: unable to start container process: exec: "phpstan": cannot run executable found relative to current directory: unknown

This seems to be related to Go 1.19 which dropped support for executing commands from the current directory (a "dot path") as a security measurement. Obviously the Docker engine did upgrade to this Go version in the meantime.

This Docker image adds (among others) vendor/bin to the $PATH which did allow for running Composer binaries so far but this has stopped working now:

https://github.com/thecodingmachine/docker-images-php/blob/098c31b33f019fb69f45df85a14f507a4f300fb5/utils/Dockerfile.slim.blueprint#L255L262

Possible Solution

Use absolute paths in the $PATH, so /var/www/html/vendor/bin and /usr/src/app/vendor/bin instead of just vendor/bin depending on CLI/FPM/Apache variant.

Steps to Reproduce (for bugs)

1. Have a recent Docker engine (23.0 or newer)
2. Install a Composer package which provides a binary
3. Use Docker Compose or Docker exec to run that binary just by its name
4. See the error mentioned above

Context

Developing PHP-based apps. ;-)

Your Environment

• Version used: 8.1-v4-fpm-node16
• Operating System and version: Debian Sid
• Link to your project: n/a

[mistraloz]

May you run docker compose exec app composer phpstan instead ?

[mbrodala]

Sure this works but you can imagine that this a huge hassle and slows down daily development. ;-)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please update it if any action still required.

[mbrodala]

Still my suggestion stands.

[mistraloz]

I mark as request but i don't have any idea about how to manage it. If we add /var/www/html/vendor/bin and /usr/src/app/vendor/bin to the PATH, it's will depend about where the composer.json will be located. Usage of composer phpstan allow more flexibility.

[mbrodala]

Fix in an unrelated project: https://github.com/syncthing/syncthing/issues/8499

[mbrodala]

@mistraloz Not sure what you mean, Composer won't magically allow running package binaries as subcommands. So installing phpstan will not allow for composer phpstan. Instead you will need to run composer exec phpstan instead and keep in mind that this command is run by Composer. So e.g. use composer exec phpstan -- --args --for --phpstan. Not really nice IMO.

[mistraloz]

e.g. use composer exec phpstan -- --args --for --phpstan. Not really nice IMO.

Not perfect but defined to resolve this issue with the path. And you can define your phpstan command as script part of composer.json.

The alternative is to design a feature to define the PATH with an environment variable (like a PATH_EXT env who will complete the default path with a custom one). It's not a priority because it's exist another way to do it (and IMHO it's a better way).

PS: I understand that is not perfect for your specific case but we try to resolve requirements for all cases. If you use multiple compose.json or if it's at another path than WORK_DIR/vendor/bin (you can customise it in composer.json), it's will not resolve anything. The feature with PATH_EXT (or another smart way) can be implemented, i'm will not work on it (at least in v4, maybe for v5) but i will merge a PR who do that.

[mbrodala]

Well, even multiple composer.json are affected, it doesn't matter how many there are. You cannot invoke any package binary without full path anywhere anymore. So the best we can do for now is to at least restore this for the default working directory. This is better than not have this restored anywhere IMO. Or do I miss something?