-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version constraint differences between |
and ||
#11086
Comments
Perhaps that is something I should handle in |
I am not sure either as I had the impression lets see what the composer guys think about it :-) |
The reason was that |
just tested the fixed version using a snapshot build and it works now. thank you. |
The previous string `"^3.0|4.1.x-dev as 3.0.0"` isn't actually an invalid version... because `4.1.x-dev` can technically be an exact version number. However, this passed unit tests just fine due to an upstream bug in `composer` which was fixed in composer/composer#11086 / composer/composer@8618f00. So when we upgrade to a newer version of `composer` that includes this fix, the test will start failing. On composer `2.4.1`, the version string `"^3.0|4.1.x-dev as 3.0.0"` throws: ``` {"error":"Invalid version string \"^3.0|4.1.x-dev\" in \"^3.0|4.1.x-dev as 3.0.0\", the alias source must be an exact version, if it is a branch name you should prefix it with dev-"} ``` Compare with `2.5.1`, where it parses that as a valid version string, and then fails because we're currently running `php` `7.4`: ``` {"error":"Your requirements could not be resolved to an installable set of packages.\n Problem 1\n - monolog\/monolog dev-main requires php >=8.1 -> your php version (7.4.33) does not satisfy that requirement.\n - monolog\/monolog 3.x-dev is an alias of monolog\/monolog dev-main and thus requires it to be installed too.\n - Root composer.json requires monolog\/monolog ^3.0|4.1.x-dev as 3.0.0 -> satisfiable by monolog\/monolog[3.0.0-RC1, ..., 3.x-dev (alias of dev-main)].\n"} ``` I double-checked with the upstream `composer` team in composer/composer#11282 and they [confirmed this behavior](composer/composer#11282 (comment)).
The previous string `"^3.0|4.1.x-dev as 3.0.0"` isn't actually an invalid version... because `4.1.x-dev` can technically be an exact version number. However, this passed unit tests just fine due to an upstream bug in `composer` which was fixed in composer/composer#11086 / composer/composer@8618f00. So when we upgrade to a newer version of `composer` that includes this fix, the test will start failing. On composer `2.4.1`, the version string `"^3.0|4.1.x-dev as 3.0.0"` throws: ``` {"error":"Invalid version string \"^3.0|4.1.x-dev\" in \"^3.0|4.1.x-dev as 3.0.0\", the alias source must be an exact version, if it is a branch name you should prefix it with dev-"} ``` Compare with `2.5.1`, where it parses that as a valid version string, and then fails because we're currently running `php` `7.4`: ``` {"error":"Your requirements could not be resolved to an installable set of packages.\n Problem 1\n - monolog\/monolog dev-main requires php >=8.1 -> your php version (7.4.33) does not satisfy that requirement.\n - monolog\/monolog 3.x-dev is an alias of monolog\/monolog dev-main and thus requires it to be installed too.\n - Root composer.json requires monolog\/monolog ^3.0|4.1.x-dev as 3.0.0 -> satisfiable by monolog\/monolog[3.0.0-RC1, ..., 3.x-dev (alias of dev-main)].\n"} ``` I double-checked with the upstream `composer` team in composer/composer#11282 and they [confirmed this behavior](composer/composer#11282 (comment)).
The previous string `"^3.0|4.1.x-dev as 3.0.0"` isn't actually an invalid version... because `4.1.x-dev` can technically be an exact version number. However, this passed unit tests just fine due to an upstream bug in `composer` which was fixed in composer/composer#11086 / composer/composer@8618f00. So when we upgrade to a newer version of `composer` that includes this fix, the test will start failing. On composer `2.4.1`, the version string `"^3.0|4.1.x-dev as 3.0.0"` throws: ``` {"error":"Invalid version string \"^3.0|4.1.x-dev\" in \"^3.0|4.1.x-dev as 3.0.0\", the alias source must be an exact version, if it is a branch name you should prefix it with dev-"} ``` Compare with `2.5.1`, where it parses that as a valid version string, and then fails because we're currently running `php` `7.4`: ``` {"error":"Your requirements could not be resolved to an installable set of packages.\n Problem 1\n - monolog\/monolog dev-main requires php >=8.1 -> your php version (7.4.33) does not satisfy that requirement.\n - monolog\/monolog 3.x-dev is an alias of monolog\/monolog dev-main and thus requires it to be installed too.\n - Root composer.json requires monolog\/monolog ^3.0|4.1.x-dev as 3.0.0 -> satisfiable by monolog\/monolog[3.0.0-RC1, ..., 3.x-dev (alias of dev-main)].\n"} ``` I double-checked with the upstream `composer` team in composer/composer#11282 and they [confirmed this behavior](composer/composer#11282 (comment)).
(unrelated context) we are in the process of normalizing our composer.json files using composer-normalize.
normalizing leads to a change within a version contraint.
composer.json before normalizing
after normalizing (it just changed
|
to||
and added spaces):running
composer config scripts.post-install-cmd --unset
with the before-composer.json works without problems.running the same command with the after-composer.json leads to an error:
I am wondering whether there is a bug in the normalizing or the composer validation process
When I run this command:
Output of
composer diagnose
:The text was updated successfully, but these errors were encountered: