If I may add, --ignore-platform-reqs=php seems to do the trick at first, but that would ignore PHP requirements of packages completely. But I would want to keep the lower boundaries intact: I'd like to have an option that does not become a footgun if I forget to remove it from my build scripts.

Additionally it might make sense for composer to ignore unrestricted platform versions that were unknown at the point of the release. For example phpunit/phpunit:4.8.18 (requiring php: >=5.3.3) should likely not be a viable candidate when runningcomposer require phpunit/phpunit on the latest PHP nightly build.

That honestly sounds like a rabbit hole I'd rather not go in.

As for the other thing.. I'd maybe suggest --ignore-platform-reqs=php+ or some such sort of hacky syntax? Just cause I'd rather not have to propagate another flag throughout the whole mess just for this. I'm not sure how this'd work out exactly, but if it's something we really need we can have a go at it.

Do you feel this is still useful/needed? I am thinking this was kind of a temporary growing pain during the initial PHP 8 rollout, which may happen again during PHP 9, but I'm not sure it needs a general solution.

There are still packages out there that put an upper boundary on PHP (e.g. ~8.0.0). In Symfony's CI, we again fake the PHP version when running tests on PHP 8.1. So yes, I still think this is useful.

I agree with @derrabus. It's still useful. I just haven't found the time to properly look into this as this needs much more work than I initially expected.

OK, I had a closer look at this, I think it may be doable if we do some internal refactoring..

Right now RuleSetGenerator handles the ignorePlatformReqs flags, by ignoring requirements on those packages which are ignored when loading package rules. This works well as ignoring just means skipping a Constraint entirely. Doing something like --ignore-platform-reqs=php+ though would mean the requires on php have to be modified to have no upper constraint, which is nastier to implement.

However if we changed things so that Package instances have a getOperator that would be used instead of a static '==' in Pool::match() (or perhaps ideally even a getConstraint method so fully ignored packages can return a MatchAllConstraint), then we could modify the ignored platform packages to return <= $version as constraint instead of == $version. That would mean php+ ignore would make the php package match PHP_VERSION or below.

This is a bit involved though so pushing this back to 2.2 to be experimented with later.

I argue against making this addition part of the codebase.

Since wrong configurations, like the mentioned upper boundary for php versions in constraints, should be fixed in the packages. And since faking the php-version (or any extension for that matter) is already supported.

Of course I can see that it will sometimes cause issues that you want to quickly (and temporarily!) resolve.
Therefore it seems to me that adding an option to override and/or replace the contents of config.json (such as the https://getcomposer.org/doc/06-config.md#platform faking platform capabilities) would be a more useful option. So, for instance add a generic option to composer's cli, like: --config='add {...}' and: --config='replace {...}' these implementation could then also replace (or be used) by currently added command-line options that influence the configuration, like for instance the cli-option --ignore-platform-req(s).

@imme-emosol just to be clear, I'm not advocating people use this in their projects. This is more of a convenience feature for people who want to prepare their projects/libraries for future php versions without having to do >= x.y and then be able to report issues back to downstream dependencies, if necessary. Adding something like --config is way more involved, I assume, and not necessary for what I had in mind.

This feature would mainly be useful for people who want to test their codebase on bleeding-edge PHP builds. And I would consider doing so a good practice because it allows early feedback to the PHP dev team.

So, not changing the composer.json but changing the ${COMPOSER_HOME}/config.json in the CI-agent to fake the php-version will enable all of those issues without changes to composer's code, right?

While adding an additional CI step composer config platform.php 8.0.99 if version is 8.1 for example will result in almost the same behavior, it does need to be updated with every new PHP version, while having this new option in --ignore-platform-req makes it easier to keep it in for experimental builds no matter the version.

As the change seems reasonably scoped (#10318) I think why not allow it..

While adding an additional CI step composer config platform.php 8.0.99 if version is 8.1 for example will result in almost the same behavior,

not exactly, as using composer config platform.php 8.0.99 will forbid versions of a package that supports only 8.1+. So the new feature is actually superior in this regard