Composer Version Constraint on Project Level #10305
Replies: 3 comments 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
@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
Since composer 1.10.6 it has the short notice:
This does not look too bad to me. I wonder how accepted the practice is. Detailed Test Output
Another test would be to require such a package and what happens then. |
Beta Was this translation helpful? Give feedback.
-
This should be resolved by #9963 which will let you require e.g. |
Beta Was this translation helpful? Give feedback.
-
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 itsphive.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: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
(orcomposer-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.Beta Was this translation helpful? Give feedback.
All reactions