0.8.0-RC - composer-runtime-api requriement is detected as InvalidPackage that results in an error on markUsed method

[AndreasA]

Describe the bug

If the composer.json contains a requirement to composer-runtime-api in combination with 0.8.0-RC it detects as invalid package instead of usedpackage and it then tries to call markUsed which fails as invalid package does not have a markused method.

Additional information

PHP 8.1

[icanhazstring]

Thanks for bringing it up. Will take a look 👍

[icanhazstring]

Will release another RC soonish with the fix included

[VincentLanglet]

Hi @icanhazstring, why the composer-runtime-api was added to the ignored list ?

Shouldn't this "dependency" be added to the composer.json only if
Composer\InstalledVersions is used ?
https://getcomposer.org/doc/07-runtime.md#installed-versions

https://github.com/maglnet/ComposerRequireChecker is reporting an error only if I use Composer\InstalledVersions without composer-runtime-api so I would expect this library to do the opposite and to reporte I can remove composer-runtime-api from the composer when I stopped using Composer\InstalledVersions. WDYT ?

[AndreasA]

@VincentLanglet Because it has nothing directly to do with InstalledVersions. that is just one aspect for which it can be used.

It actually checks that your composer installation uses the necessary runtime api, that one wants to use in the project.

see initial paragraph: https://getcomposer.org/doc/07-runtime.md#runtime-composer-utilities

InstalledVersion is just one part of it. There are other features, e.g. 2.x can be required to ensure the usage of composer 2.x

Other parts are e.g. https://getcomposer.org/doc/07-runtime.md#autoloader-path-in-binaries

In the future it might even include more things.

with InstalledVersion composer-runtime-api is required in a certain version but that does not mean that other things do not require it as well.

It is also a simple way to require the usage of composer 2.x instead of 1.x.

Though checking for all potential usages and keeping those up-to-date for the future would also be a solution but way more complicated.

However, as mentioned many projects use this to just ensure a specific composer version is used. Especially, prior composer 2.2 which adds composer as potential dependency.

see also:
https://getcomposer.org/doc/articles/composer-platform-dependencies.md#runtime-package-composer-runtime-api
https://getcomposer.org/doc/articles/composer-platform-dependencies.md#composer-package-composer

Hope that helps!

Though maybe I am missing something as well here, if so I would like to know.

[VincentLanglet]

Though checking for all potential usages and keeping those up-to-date for the future would also be a solution but way more complicated.

This is what I would want, but I understand it would be way more complicated 😅

[AndreasA]

@VincentLanglet Sure. Maybe this can be revisited once everything else works as it should.
You can also try to create a PR. Though I am not a maintainer but a PR is usually appreciated 😄

However, personally I think determining unused packages is why more complicated then required, because if a source file uses something it definitely needs it. However, e.g. with composer-runtime-api it could basically be used in any file - in theory even by a script outside the project folder, but I think that could be ignored - there is a reason why there is an ignore option 😄

But as mentioned, it very often also is just used to require a specific composer version - especially to enforce the use of composer 2.x over 1.x as only then dependencies will be installed correctly (but composer 1 would not deny such an installation). But there is a composer option now.

However, not sure if in this case it is worth the effort as all composer installations have those dependencies - its version wouldd be more intersting, e.g. if it determines the absolute required version, so e.g. if one needs to use 2.2 or if 2.0 could be used 😄