Composer, travis-ci Zend and php versions 7.0 - 7.2

Questions Components & MVC
1

I have been working on a zend-mvc project using Doctrine, among other things, and I am somewhat naive about Composer. Until recently, my composer.json has been requiring php version 5.6 || 7.0 but I wanted to drop the 5.6 and move on. So I set the version constraint to ^7.0 || ^7.2 and ran composer update, then spent a lot of time fixing breakages. I have been using 7.2 in my web environment, and using update-alternatives to try different CLI versions when running phpunit. In my .travis.yml I have said

language: php
php:
  - 7.0
  - 7.1
  - 7.2

install:  composer install

etc. And what now happens is that under 7.1 and 7.2 it’s all good, but with 7.0 composer blows up with

  Problem 1
    - Installation request for doctrine/annotations v1.6.0 -> satisfiable by doctrine/annotations[v1.6.0].
    - doctrine/annotations v1.6.0 requires php ^7.1 -> your PHP version (7.0.25) does not satisfy that requirement.
  Problem 2
    - Installation request for doctrine/cache v1.8.0 -> satisfiable by doctrine/cache[v1.8.0].
    - doctrine/cache v1.8.0 requires php ~7.1 -> your PHP version (7.0.25) does not satisfy that requirement.
  Problem 3
    - Installation request for doctrine/collections v1.5.0 -> satisfiable by doctrine/collections[v1.5.0].
    - doctrine/collections v1.5.0 requires php ^7.1 -> your PHP version (7.0.25) does not satisfy that requirement.
  Problem 4
    - Installation request for doctrine/common v2.9.0 -> satisfiable by doctrine/common[v2.9.0].
    - doctrine/common v2.9.0 requires php ^7.1 -> your PHP version (7.0.25) does not satisfy that requirement.
  Problem 5
    - Installation request for doctrine/dbal v2.8.0 -> satisfiable by doctrine/dbal[v2.8.0].
    - doctrine/dbal v2.8.0 requires php ^7.1 -> your PHP version (7.0.25) does not satisfy that requirement.
  Problem 6
    - Installation request for doctrine/doctrine-module 2.1.5 -> satisfiable by doctrine/doctrine-module[2.1.5].
    - doctrine/doctrine-module 2.1.5 requires php ^7.1 -> your PHP version (7.0.25) does not satisfy that requirement.

et cetera. Am I doing something fundamentally wrong? Or is there something tricky about supporting both 7.0 and later versions? And is it worth it, or should I abandon 7.0 support? FWIW, I am not wedded to PHP 7.0 for any reason in particular, I just thought it would be nice to be able to say this project will run on 7.0 or later.

Thanks!

2

You should definitely abandon 7.0 as it is long off active support and security support ends in about a month right along 5.6:
https://secure.php.net/supported-versions.php
7.1 active support ends in about a month as well and you should consider going straight to 7.2 as a minimal.

The install problem you have here is due to composer.lock file that have versions of packages that do not support 7.0
Read more here: https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock

^7.0 || ^7.2 constraint is the same as ^7.0 by the way: https://getcomposer.org/doc/articles/versions.md#next-significant-release-operators

2 Likes
3

Thanks – this is very helpful. I’ll be glad to get with 7.2 as a minimum. I should have been aware of the status of 7.0, but the good news is: today I am slightly less ignorant than I was yesterday… perhaps. Thanks also for the point about the version constraint.

4

xerkus solution is 100% correct and you should definitely drop 7.0.

But in case if you stumble on a similar situation in the future, one way to solve it would be to generate composer.lock with the oldest PHP version. So instead of the usual:

composer update

you should do something like:

php7.0 `which composer` update

or maybe restart from scratch:

rm -rf vendor/ composer.lock && php7.0 `which composer` install

This would call composer with php7.0 and create a working lock file for 7.0. Then if you are lucky, those locked dependencies will also be compatible with PHP 7.2. But it’s entirely up to the packages you depend on, so it might, or might not, work.

The obvious downside to this is that you explicitly forbid PHP 7.2 to use the newest packages and you are stuck on older packages that were compatible with both PHP 7.0 and 7.2. Depending on your use-case it might be acceptable…

5

yes, thanks. I was beginning to figure this out – run composer [update|install] using the lowest PHP version you plan to support – and it well might be a good thing to understand in the future. For now I’m totally happy with minimum PHP 7.2. phpunit runs so much faster, it’s remarkable!

6

Can you please explain what composer does differently depending on which PHP version it’s run with? I haven’t heard of that before.

7

It’s doing nothing more than resolving requirements according to the current PHP version. So if your package, or one of its dependencies, declare a dependency on a specific PHP version, then it will affect the result of the resolve process.

Related to that is the --ignore-platform-reqs argument for several commands as described in the docs:

–ignore-platform-reqs: ignore php , hhvm , lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.

I’d recommend against using that argument unless if you understand well the risks it can bring.

8

Oh, THAT’S how composer knows the PHP version… by the version that’s actually running composer! I always thought it was looking on the PATH or something.

Lightbulb. Thanks for that.