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.