1.15.0 breaks CI pipelines

[mwernaert]

PHP version: 8.1.15 Composer version: 2.5.2 Description

Composer asks if I want to trust "php-http/discovery" when 1.15.0 gets required. This breaks CI pipelines when php-http/discovery is an indirect dependency.

How to reproduce composer require php-http/discovery

Possible Solution Use a new major version (2.0.0) for breaking changes.

Additional context $ composer require php-http/discovery ./composer.json has been created Running composer update php-http/discovery Loading composer repositories with package information Updating dependencies Lock file operations: 1 install, 0 updates, 0 removals

• Locking php-http/discovery (1.15.0) Writing lock file Installing dependencies from lock file (including require-dev) Package operations: 1 install, 0 updates, 0 removals php-http/discovery contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins Do you trust "php-http/discovery" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?]

[Cluster2a]

You might want to add this to your composer.json and set it to false - so this plugin is being skipped.

[ambroisemaupate]

Same issue here.

If I allow php-http/discovery plugins, composer update is calling itself in loop until I kill it (#211).

[clxmstaab]

came here to report this very same problem. it seems adding a composer plugin is kind of a breaking change and should use a new major version.

we depend on php-http/discovery only as a transitive dependency and still the latest release breaks CI which is unfortunate.

[vitalij-vladimirov]

Same issue. Locked php-http/discovery to version 1.14.3 and pipeline passed. Will wait for bugfix now.

[thomasnordahl-dk]

Same issue here. First impression is that is seems a bit "much" to install dependencies like that. Isn't the point of PSR libraries to offer dependency inversions for common use cases / components?

[zlodes]

Same here. Can be temporary fixed with conflict

"conflict": {
  "php-http/discovery": "1.15.0"
},

[frsmoray]

Same issue here

[nicolas-grekas]

Adding conflict or locking are the worst solutions. The right solution is to disable the plugin, you likely don't need it anyway in your CI:

"allow-plugins": {
    "php-http/discovery": false
 }

This can be done on the command line with composer config --no-plugins allow-plugins.php-http/discovery false

[nicolas-grekas]

My analysis: no BC break here. Breaking CI is what they are for: detecting something you might need to adapt to. This is especially true for CI that run composer update (as opposed to composer install with locked dependencies), which is the case if your CI broke after v1.15.0.

[mwernaert]

Enforcing a manual change in composer.json is no problem for local dev environments, but you are asking people to update hundreds of projects due to a change in a minor version of an indirect dependency. That's breaking enough in my opinion.

[FiHoEco]

It's also a dependency that we don't personally have. Sentry includes this package so it's not as easy as just setting it to false ourselves.

[nicolas-grekas]

Here is the command-line to do it if needed: composer config --no-plugins allow-plugins.php-http/discovery [true|false]

The rationale behind the current behavior of composer is described in https://github.com/composer/composer/issues/10912 It'd be great to allow a plugin to declare that it's fine to skip it in non interactive mode.

[AndreasA]

This is definitely a breaking change, as e.g. also create-projects can now fail - where one cannot change the allow-plugins before initial setup - at least not without using --no-install.

e.g. an issue for composer create-project sulu/skeleton:^2.5.6 fails. it works with --no-plugins but it is a bit annoying and in any case it is definitely a breaking change.

It would have been better to create a separate package for the plugin, that one can install or not.

[nicolas-grekas]

Backward compatibility is not about ensuring stability of installation commands. It's about the API of PHP code.

Thanks for the hint for Sulu, here is the fix: https://github.com/sulu/skeleton/pull/212

[thomasnordahl-dk]

It might not count as a BC break in the sense that the APIs and so on remain unchanged. But this change is definitely highly disruptive, and achieves a feature, I don't really understand why you would want.

As I understand the point of having the generic interfaces from PSR, is that we should be able to depend solely on the interface and not worry about concrete implementations. So forcing specific implementations seems counterproductive to me.

Also for highly modular setups, it's not about just adjusting one composer.json, but going through a lot of individual packages, to allow or disallow something I didn't ask for in the first place. And I actually don't even want it. I actually just wanted a multipart stream builder, but now I have to deal with this due to php-http/multipart-stream-builder having a dependency on this package.

Since Composer 2.2, my colleagues and I have actually made efforts to avoid packages that uses composer plugins. It shouldn't generally be necessary to hook into the package manager like that, and it is just unwanted overhead to have to consider if a script that you didn't ask for is allowed to run or not. (In most cases we get these plugins as a dependency of a dependency).

[nicolas-grekas]

@thomasnordahl-dk that another discussion. You might want to check https://github.com/FriendsOfPHP/well-known-implementations for some explanations about why this fills a hole in the ecosystem. But it's fine to disable the plugin if you want explicit manual control over your deps. The good news with the new approach is that you won't be forced to install fallback packages anymore, as many third party libs currently require since there is no other way to provide a nice out-of-the-box experience.

[Seldaek]

One big takeaway here is that CI should not run interactive, make sure you have -n (or --no-interaction) in your Composer commands. If you do that Composer will automatically reject any new plugin (it'll output a warning but will not block). Sorry my bad, this will fail hard but at least it won't block forever. Solution is definitely to explicitly allow or reject the plugin via the allow-plugins config.

You can also set COMPOSER_NO_INTERACTION=1 in your environment variables in CI if that is easier.

[Tofandel]

It might be disruptive but is indeed not a direct breaking change, because if your CI fails because of an added plugin, it was not implemented correctly in the first place because it means you are not running composer in non interactive mode in your CI pipeline

Make sure you use the -n option in your CI script

composer upgrade -n

@Seldaek beat me to it

[AndreasA]

Using create-project with non-interactive still fails if the referenced project does not have the corresponding allow-plugin section.

[PhilETaylor]

My 2cents... I manually ran composer update - said yes to this plugin - and now composer update never ever completes, it just keeps running and running, over and over and over again... surely that cannot be the expected feature? (on my Mac, interactively)

[Tofandel]

Yes this is a bug in the plugin, being discussed in the PR

[ekes]

Guess this becomes my problem not the packages. But in a CI that I can't edit top level composer.json and that is non interactive https://www.drupal.org/pift-ci-job/2589961 it stops.

[mwernaert]

I have composer running with --no-interaction. What I should have mentioned is that it fails later on due to "php-http/discovery contains a Composer plugin which is blocked by your allow-plugins config."

[PhilETaylor]

Yes this is a bug in the plugin, being discussed in https://github.com/php-http/discovery/pull/208

Awesome - thanks. So there are two conversations, 1 is the bug and 1 is for the non-interactive nature.

[nicolas-grekas]

I'm checking the bug now.

@ekes check the last line of https://github.com/php-http/discovery/issues/213#issuecomment-1424271561

[AndreasA]

When using something like:

composer create-project --no-interaction sulu:skeleton:^2.0

even

COMPOSER_NO_INTERACTION=1 composer create-project --no-interaction sulu:skeleton:^2.0

it fails to successfully create the project due to the plugin. Is this a bug in composer (latest version), sulu skeleton or this plugin? In any case it should not happen, especially with no interaction.

Though I see you already created a PR for sulu but I fear there are other projects with similar issues.

[AndreasA]

The safest way I found for now was to use composer create-project --no-install ..., then adjust the config and then install manually. a bit annyoing though 😄

[clxmstaab]

One big takeaway here is that CI should not run interactive, make sure you have -n (or --no-interaction) in your Composer commands.

@Seldaek we run the CI in a library, which does not contain a composer.lock. even when running with COMPOSER_NO_INTERACTION=1 the CI breaks with the 1.15.0 release after composer install using ramsey/composer-install

2023-02-09T13:13:20.1602042Z ##[group]Run ramsey/composer-install@v2
2023-02-09T13:13:20.1602285Z with:
2023-02-09T13:13:20.1602538Z   composer-options: --prefer-dist --no-progress
2023-02-09T13:13:20.1602818Z   dependency-versions: locked
2023-02-09T13:13:20.1603032Z env:
2023-02-09T13:13:20.1603234Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:20.1603472Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:20.1603697Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:20.1603928Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:20.1604146Z ##[endgroup]
2023-02-09T13:13:20.1621564Z ##[group]Run ${GITHUB_ACTION_PATH}/bin/php_version.sh
2023-02-09T13:13:20.1621976Z ${GITHUB_ACTION_PATH}/bin/php_version.sh
2023-02-09T13:13:20.1670622Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-02-09T13:13:20.1670884Z env:
2023-02-09T13:13:20.1671094Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:20.1671337Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:20.1671563Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:20.1671821Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:20.1672044Z ##[endgroup]
2023-02-09T13:13:20.2700402Z ##[group]Run ${GITHUB_ACTION_PATH}/bin/should_cache.sh ""
2023-02-09T13:13:20.2700735Z ${GITHUB_ACTION_PATH}/bin/should_cache.sh ""
2023-02-09T13:13:20.2752782Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-02-09T13:13:20.2753053Z env:
2023-02-09T13:13:20.2753259Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:20.2753498Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:20.2753727Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:20.2753963Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:20.2754195Z ##[endgroup]
2023-02-09T13:13:20.2877416Z ##[group]Run ${GITHUB_ACTION_PATH}/bin/composer_paths.sh \
2023-02-09T13:13:20.2877765Z ${GITHUB_ACTION_PATH}/bin/composer_paths.sh \
2023-02-09T13:13:20.2878015Z   "" \
2023-02-09T13:13:20.2878206Z   "" \
2023-02-09T13:13:20.2878411Z   "/usr/bin/php"
2023-02-09T13:13:20.2927136Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-02-09T13:13:20.2927392Z env:
2023-02-09T13:13:20.2927602Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:20.2927847Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:20.2928158Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:20.2928393Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:20.2928617Z ##[endgroup]
2023-02-09T13:13:21.0569449Z ##[group]Run ${GITHUB_ACTION_PATH}/bin/cache_key.sh \
2023-02-09T13:13:21.0569792Z ${GITHUB_ACTION_PATH}/bin/cache_key.sh \
2023-02-09T13:13:21.0570044Z   "Linux" \
2023-02-09T13:13:21.0570242Z   "8.0.27" \
2023-02-09T13:13:21.0570457Z   "locked" \
2023-02-09T13:13:21.0570711Z   "--prefer-dist --no-progress" \
2023-02-09T13:13:21.0571062Z   "4c80cd3c3837a4115fc4acf235f86d78b906db8ae35a22bfaefd2c161cf61d12" \
2023-02-09T13:13:21.0571356Z   "" \
2023-02-09T13:13:21.0571544Z   "" \
2023-02-09T13:13:21.0571729Z   ""
2023-02-09T13:13:21.0624040Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-02-09T13:13:21.0624308Z env:
2023-02-09T13:13:21.0624522Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:21.0624767Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:21.0624993Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:21.0625226Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:21.0625450Z ##[endgroup]
2023-02-09T13:13:21.0851006Z ##[group]Run actions/cache@v3
2023-02-09T13:13:21.0851227Z with:
2023-02-09T13:13:21.0851438Z   path: /home/runner/.cache/composer
2023-02-09T13:13:21.0852014Z   key: Linux-php-8.0.27-composer---prefer-dist---no-progress-locked-4c80cd3c3837a4115fc4acf235f86d78b906db8ae35a22bfaefd2c161cf61d12
2023-02-09T13:13:21.0852722Z   restore-keys: Linux-php-8.0.27-composer---prefer-dist---no-progress-locked-

2023-02-09T13:13:21.0853102Z   enableCrossOsArchive: false
2023-02-09T13:13:21.0853350Z   fail-on-cache-miss: false
2023-02-09T13:13:21.0853560Z env:
2023-02-09T13:13:21.0853760Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:21.0854114Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:21.0854342Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:21.0854566Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:21.0854945Z   CACHE_RESTORE_KEY: Linux-php-8.0.27-composer---prefer-dist---no-progress-locked-
2023-02-09T13:13:21.0855294Z ##[endgroup]
2023-02-09T13:13:22.5542696Z Received 50331648 of 132687391 (37.9%), 47.9 MBs/sec
2023-02-09T13:13:23.3299119Z Received 132687391 of 132687391 (100.0%), 71.2 MBs/sec
2023-02-09T13:13:23.3300842Z Cache Size: ~127 MB (132687391 B)
2023-02-09T13:13:23.3325827Z [command]/usr/bin/tar -xf /home/runner/work/_temp/4b3de17b-62c4-4a6d-a356-b2119dcfde10/cache.tzst -P -C /home/runner/work/php-clxproductnet/php-clxproductnet --use-compress-program unzstd
2023-02-09T13:13:23.6253392Z Cache restored successfully
2023-02-09T13:13:23.6525482Z Cache restored from key: Linux-php-8.0.27-composer---prefer-dist---no-progress-locked-38427e49f027c02822ec9d9be88c7395feed13fcd4cc726bd118166031ff3e68
2023-02-09T13:13:23.7095007Z ##[group]Run ${GITHUB_ACTION_PATH}/bin/composer_install.sh \
2023-02-09T13:13:23.7095400Z ${GITHUB_ACTION_PATH}/bin/composer_install.sh \
2023-02-09T13:13:23.7095670Z   "locked" \
2023-02-09T13:13:23.7095934Z   "--prefer-dist --no-progress" \
2023-02-09T13:13:23.7096190Z   "" \
2023-02-09T13:13:23.7096404Z   "/usr/bin/php" \
2023-02-09T13:13:23.7096650Z   "/usr/local/bin/composer" \
2023-02-09T13:13:23.7096883Z   ""
2023-02-09T13:13:23.7149686Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2023-02-09T13:13:23.7149962Z env:
2023-02-09T13:13:23.7150187Z   COMPOSER_PROCESS_TIMEOUT: 0
2023-02-09T13:13:23.7150438Z   COMPOSER_NO_INTERACTION: 1
2023-02-09T13:13:23.7150671Z   COMPOSER_NO_AUDIT: 1
2023-02-09T13:13:23.7150916Z   MSYS: winsymlinks:nativestrict
2023-02-09T13:13:23.7151309Z   CACHE_RESTORE_KEY: Linux-php-8.0.27-composer---prefer-dist---no-progress-locked-
2023-02-09T13:13:23.7151666Z ##[endgroup]
2023-02-09T13:13:23.8654988Z Loading composer repositories with package information
2023-02-09T13:13:24.1357786Z Warning from https://repo.packagist.com/complex-gmbh: 
2023-02-09T13:13:24.1358757Z You are using a read-only authentication token, if you're running composer update, composer require, or composer install without a lock file, no new packages will be mirrored.
2023-02-09T13:13:25.2610849Z Updating dependencies
2023-02-09T13:13:25.2805222Z Lock file operations: 91 installs, 0 updates, 0 removals
2023-02-09T13:13:25.2806646Z   - Locking bamarni/composer-bin-plugin (1.8.2)
2023-02-09T13:13:25.2807296Z   - Locking bramus/ansi-php (3.1)
2023-02-09T13:13:25.2808730Z   - Locking clue/stream-filter (v1.6.0)
2023-02-09T13:13:25.2809315Z   - Locking complex/clxdeployer-recipies (2.44.2)
2023-02-09T13:13:25.2809847Z   - Locking complex/clxfrontendcms (14.0)
2023-02-09T13:13:25.2810536Z   - Locking complex/legacy (1.2.2)
2023-02-09T13:13:25.2811531Z   - Locking complex/library-installer-plugin (1.5.2)
2023-02-09T13:13:25.2812027Z   - Locking complex/rocket (dev-CLX6_2022R02_LTS 877920a)
2023-02-09T13:13:25.2812418Z   - Locking complex/utils (1.5.3)
2023-02-09T13:13:25.2812802Z   - Locking composer/installers (v2.2.0)
2023-02-09T13:13:25.2813254Z   - Locking composer/package-versions-deprecated (1.11.99.5)
2023-02-09T13:13:25.2813686Z   - Locking deployer/deployer (v6.9.0)
2023-02-09T13:13:25.2814095Z   - Locking deployer/phar-update (v2.2.0)
2023-02-09T13:13:25.2814492Z   - Locking divineomega/do-file-cache (v2.0.6)
2023-02-09T13:13:25.2814915Z   - Locking divineomega/do-file-cache-psr-6 (v2.0.1)
2023-02-09T13:13:25.2815346Z   - Locking divineomega/password_exposed (v3.2.0)
2023-02-09T13:13:25.2816031Z   - Locking divineomega/psr-18-guzzle-adapter (v1.2.0)
2023-02-09T13:13:25.2816437Z   - Locking filp/whoops (2.14.6)
2023-02-09T13:13:25.2816827Z   - Locking graham-campbell/result-type (v1.1.0)
2023-02-09T13:13:25.2817218Z   - Locking guzzlehttp/guzzle (7.5.0)
2023-02-09T13:13:25.2817594Z   - Locking guzzlehttp/promises (1.5.2)
2023-02-09T13:13:25.2817962Z   - Locking guzzlehttp/psr7 (2.4.3)
2023-02-09T13:13:25.2818317Z   - Locking hashids/hashids (4.1.0)
2023-02-09T13:13:25.2818823Z   - Locking http-interop/http-factory-guzzle (1.1.1)
2023-02-09T13:13:25.2819248Z   - Locking ion-bazan/composer-diff (v1.7.0)
2023-02-09T13:13:25.2819650Z   - Locking jaybizzle/crawler-detect (v1.2.113)
2023-02-09T13:13:25.2820032Z   - Locking knplabs/github-api (v3.9.0)
2023-02-09T13:13:25.2820434Z   - Locking lesstif/php-jira-rest-client (3.1.1)
2023-02-09T13:13:25.2820835Z   - Locking matthiasmullie/minify (1.3.70)
2023-02-09T13:13:25.2821234Z   - Locking matthiasmullie/path-converter (1.1.3)
2023-02-09T13:13:25.2821617Z   - Locking monolog/monolog (2.9.1)
2023-02-09T13:13:25.2821984Z   - Locking netresearch/jsonmapper (v4.1.0)
2023-02-09T13:13:25.2822347Z   - Locking nyholm/psr7 (1.5.1)
2023-02-09T13:13:25.2822705Z   - Locking onelogin/php-saml (3.6.1)
2023-02-09T13:13:25.2823101Z   - Locking paragonie/certainty (v2.8.2)
2023-02-09T13:13:25.2823511Z   - Locking paragonie/constant_time_encoding (v2.6.3)
2023-02-09T13:13:25.2823919Z   - Locking paragonie/random_compat (v9.99.100)
2023-02-09T13:13:25.2824313Z   - Locking paragonie/sodium_compat (v1.19.0)
2023-02-09T13:13:25.2824715Z   - Locking paypal/paypal-checkout-sdk (1.0.2)
2023-02-09T13:13:25.2825101Z   - Locking paypal/paypalhttp (1.0.1)
2023-02-09T13:13:25.2827179Z   - Locking php-http/cache-plugin (1.7.5)
2023-02-09T13:13:25.2827864Z   - Locking php-http/client-common (2.6.0)
2023-02-09T13:13:25.2828468Z   - Locking php-http/discovery (1.15.0)
2023-02-09T13:13:25.2828860Z   - Locking php-http/httplug (2.3.0)
2023-02-09T13:13:25.2829229Z   - Locking php-http/message (1.13.0)
2023-02-09T13:13:25.2829622Z   - Locking php-http/message-factory (v1.0.2)
2023-02-09T13:13:25.2830227Z   - Locking php-http/multipart-stream-builder (1.2.0)
2023-02-09T13:13:25.2830900Z   - Locking php-http/promise (1.1.0)
2023-02-09T13:13:25.2831440Z   - Locking php-parallel-lint/php-parallel-lint (v1.3.2)
2023-02-09T13:13:25.2831870Z   - Locking phpmailer/phpmailer (v6.7.1)
2023-02-09T13:13:25.2833747Z   - Locking phpoption/phpoption (1.9.0)
2023-02-09T13:13:25.2834560Z   - Locking phpstan/phpstan (1.9.17)
2023-02-09T13:13:25.2835064Z   - Locking pimple/pimple (v3.5.0)
2023-02-09T13:13:25.2835850Z   - Locking psr/cache (1.0.1)
2023-02-09T13:13:25.2836503Z   - Locking psr/container (2.0.1)
2023-02-09T13:13:25.2836979Z   - Locking psr/http-client (1.0.1)
2023-02-09T13:13:25.2837436Z   - Locking psr/http-factory (1.0.1)
2023-02-09T13:13:25.2837876Z   - Locking psr/http-message (1.0.1)
2023-02-09T13:13:25.2838302Z   - Locking psr/log (1.1.4)
2023-02-09T13:13:25.2838780Z   - Locking ralouphie/getallheaders (3.0.3)
2023-02-09T13:13:25.2839225Z   - Locking rdlowrey/auryn (v1.4.4)
2023-02-09T13:13:25.2839821Z   - Locking recombee/php-api-client (v4.1.0)
2023-02-09T13:13:25.2840288Z   - Locking rector/rector (0.15.13)
2023-02-09T13:13:25.2840719Z   - Locking rmccue/requests (v1.8.1)
2023-02-09T13:13:25.2841172Z   - Locking robrichards/xmlseclibs (3.1.1)
2023-02-09T13:13:25.2841614Z   - Locking sabre/event (5.1.4)
2023-02-09T13:13:25.2842034Z   - Locking sabre/uri (2.2.4)
2023-02-09T13:13:25.2842446Z   - Locking sabre/xml (2.2.5)
2023-02-09T13:13:25.2842885Z   - Locking staabm/sql-parser-util (1.0)
2023-02-09T13:13:25.2843414Z   - Locking staabm/sysmonitor (1.0.4)
2023-02-09T13:13:25.2843864Z   - Locking staabm/thincache (1.0.5)
2023-02-09T13:13:25.2844311Z   - Locking stomp-php/stomp-php (4.6.1)
2023-02-09T13:13:25.2844770Z   - Locking symfony/console (v5.4.19)
2023-02-09T13:13:25.2845249Z   - Locking symfony/deprecation-contracts (v2.5.2)
2023-02-09T13:13:25.2845744Z   - Locking symfony/options-resolver (v5.4.19)
2023-02-09T13:13:25.2846227Z   - Locking symfony/polyfill-ctype (v1.27.0)
2023-02-09T13:13:25.2846736Z   - Locking symfony/polyfill-intl-grapheme (v1.27.0)
2023-02-09T13:13:25.2847255Z   - Locking symfony/polyfill-intl-normalizer (v1.27.0)
2023-02-09T13:13:25.2847764Z   - Locking symfony/polyfill-mbstring (v1.27.0)
2023-02-09T13:13:25.2848254Z   - Locking symfony/polyfill-php73 (v1.27.0)
2023-02-09T13:13:25.2848725Z   - Locking symfony/polyfill-php80 (v1.27.0)
2023-02-09T13:13:25.2849172Z   - Locking symfony/process (v5.4.19)
2023-02-09T13:13:25.2849672Z   - Locking symfony/service-contracts (v1.1.2)
2023-02-09T13:13:25.2850132Z   - Locking symfony/string (v5.4.19)
2023-02-09T13:13:25.2850588Z   - Locking symfony/var-dumper (v5.4.19)
2023-02-09T13:13:25.2851031Z   - Locking symfony/yaml (v5.4.19)
2023-02-09T13:13:25.2851509Z   - Locking symplify/easy-coding-standard (11.2.8)
2023-02-09T13:13:25.2851980Z   - Locking tecnickcom/tcpdf (6.6.2)
2023-02-09T13:13:25.2852420Z   - Locking vlucas/phpdotenv (v5.5.0)
2023-02-09T13:13:25.2852872Z   - Locking webmozart/assert (1.11.0)
2023-02-09T13:13:25.2853359Z   - Locking zendframework/zendframework1 (1.12.20)
2023-02-09T13:13:25.2856531Z Writing lock file
2023-02-09T13:13:25.2857050Z Installing dependencies from lock file (including require-dev)
2023-02-09T13:13:25.2892514Z Package operations: 91 installs, 0 updates, 0 removals
2023-02-09T13:13:25.2902165Z   - Downloading php-http/discovery (1.15.0)
2023-02-09T13:13:25.4084475Z   - Installing bamarni/composer-bin-plugin (1.8.2): Extracting archive
2023-02-09T13:13:25.9063293Z ##[error]php-http/discovery contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe.
You can run "composer config --no-plugins allow-plugins.php-http/discovery [true|false]" to enable it (true) or disable it explicitly and suppress this exception (false)
See https://getcomposer.org/allow-plugins
2023-02-09T13:13:25.9071296Z 
2023-02-09T13:13:25.9114935Z In PluginManager.php line 738:
2023-02-09T13:13:25.9115348Z                                                                                
2023-02-09T13:13:25.9115816Z   php-http/discovery contains a Composer plugin which is blocked by your allo  
2023-02-09T13:13:25.9116417Z   w-plugins config. You may add it to the list if you consider it safe.        
2023-02-09T13:13:25.9117120Z   You can run "composer config --no-plugins allow-plugins.php-http/discovery   
2023-02-09T13:13:25.9117636Z   [true|false]" to enable it (true) or disable it explicitly and suppress thi  
2023-02-09T13:13:25.9118071Z   s exception (false)                                                          
2023-02-09T13:13:25.9118514Z   See https://getcomposer.org/allow-plugins                                    
2023-02-09T13:13:25.9118925Z                                                                                

using

==> Setup PHP
✓ PHP Installed PHP 8.0.27

==> Setup Tools
✓ composer Added composer 2.5.2

in a github action runner

Operating System
  Ubuntu
  22.04
  LTS
Runner Image
  Image: ubuntu-22.04
  Version: 20230206
Runner Image Provisioner  2.0.108

[Tofandel]

I think this highlights some undesirable behavior in composer, --no-interaction without an explicitely disabled or enabled plugin should just default to not enabled with a warning and not fail

But this is already the case for me on composer 2.2.6 and composer 2.5.2 which composer version are y'all running?

[naderman]

@Tofandel See the discussion linked earlier on the Composer repo, why silent disabling of required Composer plugins is a terrible idea. These are often used for very necessary operations like placing files in correct locations. So disabling the plugin without failing in non interactive mode is typically even worse than erroring in CI and letting you fix the problem as you see fit. That said, I agree with Nicolas, that Composer could offer a flag for plugins to say they are fine to be ignored, if their purpose is something you can safely disable without major negative consequences, as you could here.

[zlodes]

Agree with @nicolas-grekas. There is no breaking changes.

But it isn't about backward compatibility, it is about a bug with composer stuck in a infinite loop. 🔄

[naderman]

@zlodes Composer does not get suck in an infinite loop if you use it correctly. If you run it in an automated way you need to use non-interactive mode, see above comments.

[Tofandel]

I think this thread is getting a bit out of hand, and sadly not very constructive

I'd suggest reverting the PR with a new minor, fix the infinite install issue and then rerelease as a major

This would solve a lot of headaches

[zlodes]

@naderman I'm running composer update locally (from terminal) with plug-in added to allowed and it stuck.

[zlodes]

I'll debug it a bit later.

[Tofandel]

@zlodes take a minute to read the thread and you'll understand that yes there is a bug, and yes this is already being discussed and yes you can just disable the plugin to avoid it

Yes this is a bug in the plugin, being discussed in the PR

Adding conflict or locking are the worst solutions. The right solution is to disable the plugin, you likely don't need it anyway in your CI:

"allow-plugins": {
    "php-http/discovery": false
 }

This can be done on the command line with composer config --no-plugins allow-plugins.php-http/discovery false

[nicolas-grekas]

The infinite loop will be fixed by https://github.com/php-http/discovery/pull/214

[nicolas-grekas]

Releasing a new major version will not help in any way: as soon as a library requires discovery ^1|^2, the failure will come back again. I do understand that it's annoying, but there is not other way to push this forward unfortunately. Even creating a new dedicated package only for the plugin won't help. It's a bit like when composer introduced the check: projects had to adapt (but no prod broke.) The improvement to composer we discussed is another solution, but it would need time to propagate to the community so in the end, listing the plugin in failing projects is likely going to take the same time. (it took only a few weeks for the community to adapt to the new behavior of composer.)

[AndreasA]

In a way I also think that the main issue is that composer does not seem to have an option where plugins that are not defined in the allowed-plugin list are assumed to be disallowed, which could be used in combination with no-interaction in e.g. CI/CD enviornments or other automation scripts.

Sure, the user would not use the new plugin then but that was basically the same as prior to the dependency update. I created a corresponding composer issue - as the only one I found that fit the bill was closed already with some info text being added to the CLI output (https://github.com/composer/composer/issues/11314).

[jefhar]

Would it expect too much to have this added to the docs somewhere?

Adding conflict or locking are the worst solutions. The right solution is to disable the plugin, you likely don't need it anyway in your CI:

"allow-plugins": { 
    "php-http/discovery": false
 }

This can be done on the command line with composer config --no-plugins allow-plugins.php-http/discovery false

[AndreasA]

one solution I found to avoid tihngs like this in the future is to run:

composer config --no-plugins allow-plugins.* false # Disable all non allowed plugins.

and if a new plugin is supposed to be allowed:

composer config --unset --no-plugins allow-plugins.* # Needed to ensure correct order if this is already set.
composer config --no-plugins allow-plugins.<plugin> true # Allow new plugin necessary plugins.
composer config --no-plugins allow-plugins.* false # Disable all other plugins again.

the disadvantage is that one is never notified about potentially new plugins. and that config is always active - independent of CI/CD.

Though it could probably be set in CI/CD temporarily. In which case it would always be at the end, so

composer config --no-plugins allow-plugins.* false

would be enough.

Though I am not sure if the order of allow-plugins is always used as it is defined in the file.

So in case of create-project it would be:

composer create-project sulu:skeleton:^2.0 --no-install
composer config --no-plugins allow-plugins.* false
composer install

[nicolas-grekas]

the main issue is that composer does not seem to have an option where plugins that are not defined in the allowed-plugin list are assumed to be disallowed

:100: this

Here is a PR to improve composer in this regards: https://github.com/composer/composer/pull/11315

This would close this issue.

[AndreasA]

Here is a PR to improve composer in this regards: composer/composer#11315

This would close this issue.

It would still fail if a new plugin is added that is optional but the maintainer did not use the corresponding flag. So the user has no option to just "ignore" this in the CI/CD.

Hoewver, in most cases it should be enough, as plugin developers hopefully take care of this - and if not it would probably be a breaking change anyway.

[nicolas-grekas]

Thank you all for the discussion. As far as this package is concerned, I think we did everything we could. Next step is https://github.com/composer/composer/pull/11315

[mwernaert]

Thanks for improving Composer and taking some responsibility. I still think it would have been wiser to revert the breaking change in a 1.15.1 release and push the new plugin in a 2.0 version. While I agree that sooner or later people will have to deal with allowing/disallowing the plugin, the push could have been done more gracefully. Giving package maintainers (like Sentry) a choice and chance to stick to a specific version for now, bump a major as well later on (and communicate why) or replace the dependency. I don't want to nag too much about this because it is easily resolved (and already done and communicated within my company), but the 'the damage is done, deal with it' attitude is a bit too careless for my taste. Lot's of people and package maintainers were impacted by this.

The comparison with a Composer change that required a manual change sounds fair, but people could easily compare this mistake with the left-pad NPM debacle as well.

[bensebborn]

+1 for lots of disruption caused, especially as this is just a dependancy of another package - not something we're using directly ourselves.

Consideration of the developer ecosystem needs to happen, not just brute forcing something through because it doesn't warrant a breaking chance according to standards.

[nicolas-grekas]

Composer v2.2.20 and v2.5.3 have now been released in case you missed them. Thanks @naderman and @Seldaek for the quick help!

[amenk]

I still see endless loops on composer install (no .lock present) in some situations - posted on StackOverflow because I am not sure if it is related to this module, composer or our own module.

[nicolas-grekas]

Please open a dedicated issue with the details.

[nicolas-grekas]

@amenk fixed as of 1.15.2 and #219

I'm locking this issue to encourage creating new dedicated issues if needed.