Fix builds

[jakzal]

Once there's a solution to composer/composer#10389

[hopeseekr]

I can fix it...

Point me to your build problem. I just fixed this for a large range of my own projects.

Update: I found your CI/ system. The most intractable problem you currently have is the same one I'm struggling to overcome:

For additional security you should declare the allow-plugins config with a list of packages names that are allowed to run code. See https://getcomposer.org/allow-plugins

This completely breaks just over 100+ private projects' CI/CD systems and over 90,000 public installs of my 0.0.0/composer-include-files plugin, and there doesn't seem to be any means to add plugins to the whitelist for 3rd parties.

This v2.2.0 of composer really broke a lot of stuff!! It should be v3.0.0 for all the backward incompatibilities...

[jakzal]

thanks!

It might be a problem with the way composer-bin-plugin or composer itself creates symlinks. I haven’t looked at it too deep yet. If there’s anything to change on our side it will probably be in the jakzal/toolbox repo (see failing builds there).

the problem with allowed-plugins isn’t critical until next year.

[Seldaek]

For additional security you should declare the allow-plugins config with a list of packages names that are allowed to run code. See https://getcomposer.org/allow-plugins

This is simply a warning and it should not break any builds. We explicitly built this in with a grace period of six months so that we do not disrupt anything and give people time to update their composer.json files. That said yes please do fix it before it becomes a problem. It only requires you to list the plugins like "allow-plugins": {"foo/bar": true}, this shouldn't be a ton of work, and it anyway won't have any effect on the end users of your package as they are the ones that have to allow plugins to execute in their projects, your composer.json config has no impact on theirs.

It might be a problem with the way composer-bin-plugin or composer itself creates symlinks. I haven’t looked at it too deep yet. If there’s anything to change on our side it will probably be in the jakzal/toolbox repo (see failing builds there).

Yes that's more or less what it is, see composer/composer#10402 for an explanation and a way to fix. I'd be curious to get feedback from people encountering issues. I couldn't find exactly the source of /tools/php-coupling-detector for toolbox, so I am not sure what it's looking like, but I assume it's doing something similar.

[jakzal]

Thanks @Seldaek. It seems we're having issues with links to composer created scripts in combination with composer-bin-plugin.

i.e.

This works fine:

composer global require bamarni/composer-bin-plugin
composer global bin tools require akeneo/php-coupling-detector
~/.composer/vendor-bin/php-coupling-detector/vendor/bin/php-coupling-detector

This doesn't:

ln -sf ${COMPOSER_HOME:-"~/.composer"}/vendor-bin/php-coupling-detector/vendor/bin/php-coupling-detector /usr/local/bin/php-coupling-detector
/usr/local/bin/php-coupling-detector

/usr/local/bin/php-coupling-detector: cd: line 3: can't cd to ../akeneo/php-coupling-detector/bin: No such file or directory
/usr/local/bin/php-coupling-detector: line 16: /php-coupling-detector: not found

composer 2.2.2

[jakzal]

Actually, it's unrelated to composer-bin-plugin:

/toolbox # composer global require akeneo/php-coupling-detector -q
/toolbox # composer self-update
You are already using the latest available Composer version 2.2.2 (stable channel).
/toolbox # composer global require akeneo/php-coupling-detector -q
/toolbox #
/toolbox #
/toolbox # ln -s ~/.composer/vendor/bin/php-coupling-detector /usr/local/bin/php-coupling-detector
/toolbox # /usr/local/bin/php-coupling-detector
/usr/local/bin/php-coupling-detector: cd: line 3: can't cd to ../akeneo/php-coupling-detector/bin: No such file or directory
/usr/local/bin/php-coupling-detector: line 16: /php-coupling-detector: not found

[Seldaek]

OK I see.

So there is one bug here in that we do not detect https://github.com/akeneo/php-coupling-detector/blob/master/bin/php-coupling-detector as a php file I believe because it has a blank line before <?php - I fixed that in composer/composer@d1d5d75

But the other issue is that the symlinking you are doing is going to break the bin proxies we now create as of Composer 2.2, so if any tool you are using has a binary which is a shell script and not PHP, this will still break.

The issue is the symlink changes the resolution of cd "${0%[/\\]*}" that we do in our bin proxy to resolve the full path of the real binary from the package. For example if you have

/foo/ #project dir
/foo/vendor/bin/bla  #bin proxy created by composer
/foo/vendor/blu/bla/bin/bla #real binary from blu/bla package
/bar/bla -> /foo/vendor/bin/bla #symlink

Then when calling /foo/vendor/bin/bla, it will resolve current dir to /foo/vendor/bin and know to then find the real binary in ../blu/bla/bin/bla.

If you however call it via a symlink /bar/bla, the resolved dir is that of the symlink's location so you get /bar and now the relative path is broken.

I am not sure if that one is a solvable problem on our end or not, will need to investigate further.

[Seldaek]

I am not sure if that one is a solvable problem on our end or not, will need to investigate further.

Should be fixed by composer/composer@390260c actually.. so hopefully now with latest snapshot (composer self-update --snapshot) everything should be fine again here.

[jakzal]

Thanks @Seldaek 🍺 you're a ⭐ Problem solved!

[jakzal]

I'll update jakzal/toolbox as soon as a new composer version is released.

As for allow-plugins: jakzal/toolbox#415

[Seldaek]

2.2.3 is out now