Force composer to require PHP Version between Version X and Version Y
we have a mix of different PHP versions running on your servers (max 5.3.5) and development machines (max 5.5.9).
Now we ran into the problem that we did a "composer update" to get the latest Version of some external Bundles. Since your composer.json looks like
"require": {
"php": ">=5.3.3",
.....
},
we get some Bundles that required PHP 5.5. No problem on our dev machines, but on the server :(
Is there any possibility to tell composer to require a PHP version between 5.3.3 and 5.3.5? Or a max available Version?
I tried
"require": {
"php": ">=5.3.3, <=5.3.5",
.....
},
and
"require": {
"php": "<=5.3.5",
.....
},
but both didn't work out. I get a "The requested package php could not be found in any version, there may be a typo in the package name." Error.
Any Ideas? Thanks in advance
Solution 1:
Since the config parameter in composer.json is available. You could something like this:
{
"name": ".../...",
"config": {
"platform": {
"php": "5.3.5"
}
},
"require": {
...
}
}
https://getcomposer.org/doc/06-config.md#platform
Solution 2:
I find it questionable to say the least that you are developing with the newest PHP available and are running production with a very outdated version. There will be plenty of possible problems arising from this, not only because of security patches that you would be missing, but more importantly because of PHP bug fixes that got introduced mostly in versions 5.3.9 and 5.3.23 that changes PHP behavior in some details pretty fundamentally. Not talking about the risk of accidentally using features of 5.4 or 5.5.
And there really is no way to make Composer deal with this situation. The PHP version that is used when running composer update
determines the resolution of dependencies, being influenced by PHP version and installed PHP extensions.
You cannot define that a package should only be used for PHP versions between 5.3.3 and 5.3.5 if the PHP you are using for the update is not matching this version requirement. Because the used PHP version exceeds the upper version constraint, such a package is not eligible for fulfilling the version requirement, and Composer reports that no package has been found (not telling that it has seen the packages, but they had to be ignored because of the version constraint).
There are probably three obvious ways out:
Downgrade your development environment to the production version you are really using. If more than one is used: The oldest one. That way any requirements for PHP versions will be matched. Run
composer update
then, and you are done.Upgrade your production environment. Needs no further explanation, but I have to mention that not only are you missing a lot of very nice PHP features, you are also missing a substantial performance increase, because PHP 5.5 is really that much faster than 5.3.
Add a "platform.php" configuration to either the global or project's composer.json. This will tell Composer to override the PHP version running Composer itself, and instead calculate the dependencies with that different PHP version.
composer config -g platform.php 5.3.5
for global setting (will affect all further Composer runs), without-g
for local setting (will only affect Composer operations in that project, in case you develop on more than one project with different production versions of PHP).
Solution 3:
Try this (remove comma):
"require": {
"php": ">=5.3.3 <=5.3.5",
.....
},
Solution 4:
Remove your composer.lock and vendor directory.
Now place platform option to composer.json
"config": {
"platform": {
"php": "7.0"
}
},
and finally, run command composer install
Solution 5:
What about trying the tilde operator
Tilde Operator ~1.2 Very useful for projects that follow semantic versioning. ~1.2 is equivalent to >=1.2,<2.0. For more details, read the next section below.
Next Significant Release (Tilde Operator)#
The ~ operator is best explained by example: ~1.2 is equivalent to
=1.2,<2.0, while ~1.2.3 is equivalent to >=1.2.3,<1.3. As you can see it is mostly useful for projects respecting semantic versioning. A common usage would be to mark the minimum minor version you depend on, like ~1.2 (which allows anything up to, but not including, 2.0). Since in theory there should be no backwards compatibility breaks until 2.0, that works well. Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up.
Note: Though 2.0-beta.1 is strictly before 2.0, a version constraint like ~1.2 would not install it. As said above ~1.2 only means the .2 can change but the 1. part is fixed.
Note: The ~ operator has an exception on its behavior for the major release number. This means for example that ~1 is the same as ~1.0 as it will not allow the major number to increase trying to keep backwards compatibility.