[2.2.0] Scripts from "bin" are executed not in "bin" directory. #10389
Comments
|
Did this really work before? I suppose it should have as we push the bin-dir on to the $PATH env var, but I'm not sure what would cause this to break now.. Anyway will try and repro later thanks. |
|
@Seldaek I am not sure if it's related. Have also an issue in my Magerun builds with Composer 2.2.1 with a bin execute. In 2.1.14 it's fine. #!/usr/bin/env php
<?php declare(strict_types=1);I start |
Thanks for the context. In my case I run the tests with process isolation. |
|
@biozshock I can reproduce this but I can also reproduce it with Composer 2.1.14 so it doesn't seem to be a new problem? if I run |
|
The issue with using EDIT: also i can see the issue with adding vendor to You need to remove vendor directory before testing with 2.1.14 |
Yes it is guaranteed as the bin-dir is prepended to the path. This is done by composer BTW you don't have to add anything to your path manually. But it only works if running the binary via a composer script. If you call vendor/bin/codesniffer directly then the path wouldn't be setup. While it worked for you in 2.1 it didn't work equally in all platforms/envs, which is why your script also didn't work for me with 2.1. 2.2 normalizes things so that we have bin proxies everywhere. It may require that you adjust your path computation a bit to figure out where the other binaries are. |
|
I guess the main question here is why did |
We are also experiencing this error for vendor/bin/dep and specifically for our mage deployer ( https://github.com/unleashedtech/deployer-recipes/blob/magento2/cms/magento/magento2.php#L333 ) Tested with both composer 2.2.0 and 2.2.1 . Reverting to composer 2.1.14 then command executes fine. |
|
This is SERIOUSLY affecting my package which has several thousand users. https://packagist.org/packages/phpexperts/dockerize
In composer 2.2.0-rc1 and above: The working dir for composer vendor scripts has changed from |
|
To fix: In # @see https://linuxize.com/post/how-to-check-if-string-contains-substring-in-bash/
# @see https://github.com/composer/composer/issues/10389
SUB="/vendor/"
if [[ "$0" == *"$SUB"* ]]; then
ROOT="$(readlink -f /proc/$PPID/cwd)"
else
ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )/../.." && pwd )"
fiThis seems to work for both pre-2.2.0 and 2.2.0+. |
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
|
OK with a bit more free time now I had another look here and got a better understanding. I'd say #10402 is probably the best we can do, to allow packages with problems to solve it cleanly. Would that work for everyone? |
|
2.2.2 is now out with the new env var available https://github.com/composer/composer/releases/tag/2.2.2 |
|
Hello @Seldaek I have found another issue with this I think 🙈 . I do not believe I can any longer source scripts from Context Some parts of this process take a lot of time and travis exits early if no output is received for a while to stop builds hanging. To ensure the builds do not exit early I use the travis_wait bash function which is only available inside the default travis shell. Problem The changes introduced means that I cannot These errors seem to come from the wrapper which s now introduced by composer, specifically this line #!/usr/bin/env sh
self=$(realpath $0 >/dev/null 2>&1)
if [ -z "$self" ]
then
self="$0"
fi
dir=$(cd "${self%[/\\]*}" > /dev/null; cd '../ampersand/travis-vanilla-magento' && pwd)Replication I have distilled this issue down into a (hopefully) easily reproducible script which removes basically all the dependencies. Please see https://github.com/convenient/composer-2-2-3-issue-10389-debug-b Essentially I can get this to the point that it operates like so for me And I cannot see any way that altering Please let me know if you have any questions or if I need to clarify anything. |
|
@convenient IMO this strictly speaking misuse and thus not a bug from Composer's point of view. The use case for binaries is to execute them. symlinking stuff from the vendor dir was just an accident of history and not something you should rely on. That said it appears to be fixable reasonably easily by using $BASH_SOURCE instead of $0, I did not initially want to do that to avoid messing things up with non-bash shells, but the fallback I put in there will hopefully be enough. And for the record yes please do open a new issue next time, you are welcome to reference back to this one but it'd make it easier to have a proper changelog entry and so on if things are separated. Anyway see 6dea58c for the fix and feel free to give it a shot with |
|
@Seldaek That will execute the right script, but it will still execute it in a subshell, so the source will not have any effect. The bin proxy would have to detect this situation and use source itself to invoke the bin file. |
|
Ahh good point, should be easy enough checking that $BASH_SOURCE != $0 |
|
OK that should seems to do the job for me 24b62a1 - I checked with the target binary adding a bash alias and it gets added properly. |
|
@naderman @Seldaek Thank you both so much 🙌 Really appreciate this, using the snapshot seems to fix the issue for me. I feel a little like this XKCD comic 😬 I'm not trying to pester please forgive me if it comes across that way, but what is your release cycle like / when would you expect this to go into a stable release? Days/weeks/months? Just trying to work out my next steps for internally fixing all our repositories affected, so that I know whether I force a 2.1 version of composer or whether I wait until another 2.2 release. Thanks again |
|
Probably can do a patch release next week as we've got a few fixes lined up. |
|
Thanks @Seldaek all my builds have gone green this morning. Very much appreciated! |
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
The problem is that composer v2.2.0+ changed the way that vendor bin scripts are executed. Now they are executed by an intermediary shell script in a way that causes their PWD to change to the project's bin-dir, breaking project root detection. See composer/composer#10389
Create a composer json that require any package, which contains a bash/sh script in
bin, which executes another bin file from arequire.My
composer.json:{ "require": { "ninjify/qa": "^0.12.1" }, "scripts": { "codesniffer": "codesniffer" }, "config": { "allow-plugins": { "dealerdirect/phpcodesniffer-composer-installer": true } } }Output of
composer diagnose:When I run this command:
I get the following output:
And I expected this to happen: Command is executed.
The text was updated successfully, but these errors were encountered: