ChatGPT解决这个技术问题 Extra ChatGPT

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


N
NuSphere

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


Though this parameter is specified, the library still installs a version that is greater than specified PHP version. For example, I specified PHP version 5.4.36, but Composer still installs Symfony version 3.1.3, which requires 5.5+. Conclusion: Not working.
platform is mainly to Let you fake platform packages (PHP and extensions) so that you can emulate a production env. require is a better choice for between Version X and Version Y
This worked well for me! I needed to install packages compatible with PHP <=7.0.16
Maybe there was a bug somewhere in the chain for Raptor, but config.platform.php is intended to solve exactly the issue in this question, and it works. Maybe the composer version used didn't support it yet.
Exactly what I was looking for, thanks! Important to note that you'll need to run composer update after setting this, just like any other dependency-related change to composer.json.
S
Sven

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).


I added a new third option which should be valid for more recent versions of Composer, likely starting from 1.0.0-beta1 and up (I won't dig into the alpha release notes now to exactly tell you). Just use the stable 1.0.0 release.
@Arcesilas What do you mean? The question basically is about how to restrict Composer to select packages for too advanced versions of PHP during an update - so the lock file, while affecting the outcome of an update, is meaningless in this context.
People have constraints... not so questionable, right?
It is questionable to not use the same versions in development and production. Errors can easily slip in, like using a PHP feature that production does not have, or a bug was fixed in DEV, but is still unfixed in production. Not using the same version means that you will not experience the same behavior. Especially when mixing PHP 5.3 in prod with PHP 5.5 in dev (problems are less likely or surprising if mixing 5.5.x with 5.5.y).
Hi Sven, we do the same. Developing in a higher version, then we have in production. The reason is: that our code is future ready. So when we need to upgrade, we do not need to worry much for it is already tested. We are plain-vanilla developers without php-unit etc. because that did not exist when our framework came to life. So we have other ways of monitoring and testing our code.
M
Mike Milkman

Try this (remove comma):

"require": {
    "php": ">=5.3.3 <=5.3.5",
        .....
    },

J
Jeff Puckett

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


B
Billy

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.


w
whyer

Is there any possibility to tell composer to require a PHP version between 5.3.3 and 5.3.5?

Yes, there it is one:

Hyphenated Version Range ( - ) Inclusive set of versions. Partial versions on the right include are completed with a wildcard. For example 1.0 - 2.0 is equivalent to >=1.0.0 <2.1 as the 2.0 becomes 2.0.*. On the other hand 1.0.0 - 2.1.0 is equivalent to >=1.0.0 <=2.1.0. Example: 1.0 - 2.0 https://getcomposer.org/doc/articles/versions.md#hyphenated-version-range-

or you may use composer.json like this:

{
  "require": {
    "guzzlehttp/guzzle": ">=5.3.4 <6"
  }
}

- I personally prefer this way because it's much easier to read and remember IMHO.


P.S. I got here from search engine but didn't find an answer here, so when I found it on Composer's site I decided to post it here. Hope this helps someone who got here like I did.
There's a community guideline to remove content not directly related to the question or answer, but no "official" rule. If you feel it's integral to the answer, or just want to preserve your voice, by all means rollback my edit -- though I think leaving it as a comment is a great place for that addition. That said, thanks for your answer and +1.
@bishop thx, that was interesting to know.
Where exactly do you input this? I been struggling with this all day.
@Eduardo i've edited my answer for you - i added an example composer.json. hth!