Option to disallow non allowed-plugins by default, e.g. useful with no-interaction and automated create-project scripts

[AndreasA]

My composer.json: No initial file.

Run composer create-project --no-interaction sulu:skeleton:^2.5.6 fails currently due to a change in a dependency (or even a sub-dependency) defining a new plugin, see also php-http/discovery#213

As any required package can define a new plugin, this can be problematic during automations as one can never define all plugins that might just be added due to minor package changes.

Sure, it is a bit of an edge-case in combination with create-project but there are other potential issues with this. However, e.g. if the project creation is automated that creates the project, does various changes (e.g. install always used dependencies) etc., it will now fail and there are other potential scenarios.

It would be create to have a new flag like --disallow-undefined-plugins that automatically assumes not defined plugins (in the composer.json) are` disallowed.

Or assume this by default in combination with no-interaction (or a non interactive CLI) which would make sense anyway, as that would be the behavior before a new plugin is added.

I found that issue #10935 and the corresponding PR that informs the user about how to fix it, but that isn't that helpful actually in a CI/CD environment or with automation and here it is OK to not enable the new plugin by default - though some info output could still be helpful.

using --no-plugins is not helpful either as I might need some plugins to be active, like e.g. symfony/flex.

[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 a create-project it would be e.g.

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

[Seldaek]

I think your last workaround works well enough, but I also think this is bad. If you have a new plugin popping up in most cases the CI should fail and you should be made aware of it and decide what to do about it explicitly.

That's why composer fails hard. The php-http/discovery mess there was a bit different because in that case it is really an optional plugin but those are extremely rare as far as I can tell, and getting a new plugin package in the dependency graph is also a rare occurrence so I feel like this is an overreaction and I'd rather not do it. We have added a flag for optional plugins in https://github.com/composer/composer/releases/tag/2.5.3 tho to mitigate this.

[AndreasA]

OK. Though if one uses --no-plugins it would not fail but even less plugins would be active (none), so personally I am not sure why auto assume disallow is so bad.

but yes, hopefully with the new flag, the issue will only happen again, if the plugin is more or less required anyway in which case it should be a major version release anyway.

[Seldaek]

Sorry last workaround I meant this:

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

[AndreasA]

yes, but as mentioned it is a bit of a hacky workaround 😄
Don't really see why such an option should not available generally as --no-plugins is.

However, as you mentioned it probably is not something that will that easily re-occur in the future as with the new optional plugin, corresponding plugin should be marked accordingly.

And all others should probably be a separate package or a major verison anyway.