Composer Version Constraint on Project Level

[ktomk]

I've now been in the situation where it turned out that the composer version used with the project was not the expected one for development.

This turned out late and by that causing more headaches then necessary if this would have been checked earlier.

Albeit even in those projects composer itself is provided with a fine version via phive(1) and its phive.xml, it turned out to not be convenient enough in a development situation. The build scripts naturally took the version needed.

Now I'm thinking about how this can be improved on the project level for development.

I've peeked into composer show and found two entries:

$ tools/composer show --platform | grep composer
composer-plugin-api    2.0.0    The Composer Plugin API
composer-runtime-api   2.0.0    The Composer Runtime API

So I've used composer-runtime-api with a version constraint like 2.1.0 and found out that composer refuses to update or install if a 2.0.x version is in use.

This is already the good half of what I need for an effective blocker using an outdated composer version. Have to test against 1.x thought.

However, what I'm looking for is not the runtime-api as I don't rely on it specifically, but more the composer version in use, which is also more fine-grained. And the error message is like, yeah, a blocker ;)

In a build situation it is normally automated and within scripts I can already pin the version. This I'm doing since longer when needed and is not this issue and works pretty well.

However if for development a version check as well would be available implicitly when just invoking composer in a project (perhaps better with an option in composer.json than with a require-dev package - it is also not platform) I think it would be better.

Perhaps this is of use as well to nudge users of active projects to update composer? (I only have the best intentions, see ;) )

Perhaps others were also already in this situation and have some experiences with using composer-runtime-api (or composer-plugin-api ) for some side-effect of this kind. Or perhaps it's a totally stupid idea and I'm just blind to realize it.

[stof]

composer does not have a way to require an exact version of composer to be used (which would basically forbid you from updating composer easily, which goes against the interest of composer). This looks more like something that should be part of your higher-level tooling installing composer.

[ktomk]

@stof Yes good remark on the exact version, and in the build I have it in tooling (as well as on the project level for installing it). Perhaps I should look into a check in development supporting scripts on the composer version of the development environment.

For a version check in regard to allow upgrades (e.g. you checkout a project from Github to collaborate), it should support the common version constraints, so that the version expectation is clear (and there is the usual forward/backward compatibility).

In the concrete "incident" this was some composer 1.10.x and that one I can block with a composer-runtime-api requirement - at least from my synthetic tests. The blocker message for some composer 1 users looks a bit verbose, but it effectively prevents use (here composer 1.10.0 output):

Your requirements could not be resolved to an installable set of packages.

Problem 1

• The requested package composer-runtime-api could not be found in any version, there may be a typo in the package name.

Potential causes:

• A typo in the package name
• The package is not available in a stable-enough version according to your minimum-stability setting
  see https://getcomposer.org/doc/04-schema.md#minimum-stability for more details.
• It's a private package and you forgot to add a custom repository to find it

Read https://getcomposer.org/doc/articles/troubleshooting.md for further common problems.

Since composer 1.10.6 it has the short notice:

Your requirements could not be resolved to an installable set of packages.

Problem 1
- The requested package composer-runtime-api ^2 exists as composer-runtime-api[1.0.0] but these are rejected by your constraint.

This does not look too bad to me. I wonder how accepted the practice is.

Detailed Test Output

• composer-1-vs-2/test.bash (with A version 1.10.0)

 ./test.bash
+ set -e
+ git clean -fdx 'composer.*' vendor
+ ./composer-install.sh --quiet --version=1.10.0 --filename=a-composer
+ ./a-composer --version
Composer version 1.10.0 2020-03-10 14:08:05
+ ./composer-install.sh --quiet --version=2.0.14 --filename=b-composer
+ ./b-composer --version
Composer version 2.0.14 2021-05-21 17:03:37
+ cat -
+ tee composer.json
{
  "require": {
    "composer-runtime-api": "^2"
  }
}
+ ./a-composer install
Deprecation warning: require.composer-runtime-api is invalid, it should have a vendor name, a forward slash, and a package name. The vendor and package name can be words separated by -, . or _. The complete name should match "[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9]([_.-]?[a-z0-9]+)*". Make sure you fix this as Composer 2.0 will error.
Loading composer repositories with package information
Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package composer-runtime-api could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
+ ./b-composer install
No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
Generating autoload files

Another test would be to require such a package and what happens then.

[Seldaek]

This should be resolved by #9963 which will let you require e.g. composer: ^2.2 but only from Composer 2.2 onwards. Previuos composer versions will simply fail as the package will not be found, which is also ok I suppose. It just won't let you enforce Composer 1 usage for example (for that you could do a conflict with composer-runtime-api ^2, but really the thing to do is to upgrade to Composer 2 already ;)

[ktomk]

It's not that the user was refusing to upgrade or use a more recent composer version (nor that the project itself was not shipping with composer 2), it was just like a WTF moment because we had no clue where that composer version came from. Like installed time ago and forgotten. This kind of update problem where everybody thinks that yeah sure, we all are using composer 2 across the board. And then not.

Automation. Makes only fun with the manual interruptions from time to time.

Thanks for referencing #9963, I was not aware of it.

I guess we wait for a first working release before the backports are done, right? ^^

And, would you say that using composer-runtime-api is legit for a standard project just for the sake of getting some baseline for the composer version? @Seldaek I mean by the meaning of that package itself. I'm thinking about placing it into that project and give it a try just to prevent any accidental use of an outdated composer version. Just to not run into the same situation again unnoticed (the unintentional use of composer 1 instead of 2.x).

[Seldaek]

Sure, requiring composer-runtime-api ^2 is good enough as workaround for now, it'll have the same effect.