Composer: Php version shows 7 but composer does not work

[StepanyanAlbert]

My composer.json:

cat composer.json 
{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": ">=7.0.0",
        "barryvdh/laravel-debugbar": "^3.1",
        "fideloper/proxy": "~3.3",
        "laravel/framework": "5.5.*",
        "laravel/tinker": "~1.0"
    },
    "require-dev": {
        "filp/whoops": "~2.0",
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "~1.0",
        "phpunit/phpunit": "~6.0"
    },
    "autoload": {
        "classmap": [
            "database/seeds",
            "database/factories"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "dont-discover": [
            ]
        }
    },
    "scripts": {
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate"
        ],
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover"
        ]
    },
    "config": {
        "preferred-install": "dist",
        "sort-packages": true,
        "optimize-autoloader": true
    }
}

Output of composer diagnose:

composer diagnose
Checking composer.json: OK
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: Warning: Accessing packagist.org over http which is an insecure protocol.
OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up
Checking composer version: FAIL
You are not running the latest stable version, run `composer self-update` to update (1.1.2 => 1.5.6)

When I run this command:

composer install

I get the following output:

  Problem 1
    - This package requires php >=7.0.0 but your PHP version (5.6.32) does not satisfy that requirement.
  Problem 2
    - Installation request for barryvdh/laravel-debugbar ^3.1 -> satisfiable by barryvdh/laravel-debugbar[v3.1.0].
    - barryvdh/laravel-debugbar v3.1.0 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
  Problem 3
    - laravel/framework v5.5.9 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.8 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.7 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.6 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.5 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.4 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.3 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.26 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.25 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.24 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.23 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.22 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.21 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.20 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.2 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.19 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.18 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.17 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.16 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.15 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.14 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.13 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.12 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.11 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.10 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.1 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.0 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - Installation request for laravel/framework 5.5.* -> satisfiable by laravel/framework[v5.5.0, v5.5.1, v5.5.10, v5.5.11, v5.5.12, v5.5.13, v5.5.14, v5.5.15, v5.5.16, v5.5.17, v5.5.18, v5.5.19, v5.5.2, v5.5.20, v5.5.21, v5.5.22, v5.5.23, v5.5.24, v5.5.25, v5.5.26, v5.5.3, v5.5.4, v5.5.5, v5.5.6, v5.5.7, v5.5.8, v5.5.9].

And I expected composer to install laravel dependencies

Output of php -v

ea-php-cli Copyright 2017 cPanel, Inc.
PHP 7.0.26 (cli) (built: Dec  4 2017 16:05:39) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

Delete all kind of caches but still no success , I don't want to update composer if possible.
Thanks

[alcohol]

Pretty sure it is an issue on your end, not with Composer.

You are using cPanel, that is mistake number one.
Your Composer version is ancient (1.1.2), it should really be updated.

Please run the following commands in your project directory directly from the command line and give us the output (unaltered):

which php
which composer
composer --version
php --version
php --ini
cat composer.json

[StepanyanAlbert]

Your Composer version is ancient (1.1.2), it should really be updated.
But this is the latest stable version .
pwd
/home/s**y/www/s**y
which php
/usr/local/bin/php
which composer
/usr/local/bin/composer
composer --version
Composer version 1.1.2 2016-05-31 19:48:11
```php --version
PHP 7.0.26 (cli) (built: Dec 4 2017 16:05:39) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

```php --ini
Configuration File (php.ini) Path: /opt/cpanel/ea-php70/root/etc
Loaded Configuration File:         /opt/cpanel/ea-php70/root/etc/php.ini
Scan for additional .ini files in: /opt/cpanel/ea-php70/root/etc/php.d
Additional .ini files parsed:      /opt/cpanel/ea-php70/root/etc/php.d/02-pecl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-bcmath.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-calendar.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ctype.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-curl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-dba.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-dom.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-exif.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ftp.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-gd.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-gettext.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-iconv.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-imap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-intl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-json.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-ldap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mbstring.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mcrypt.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-mysqlnd.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-pdo.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-phar.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-posix.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-simplexml.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-soap.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-sqlite3.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-tidy.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-tokenizer.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xml.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xmlwriter.ini,
/opt/cpanel/ea-php70/root/etc/php.d/20-xsl.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-mysqli.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-pdo_mysql.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-pdo_sqlite.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-wddx.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-xmlreader.ini,
/opt/cpanel/ea-php70/root/etc/php.d/30-xmlrpc.ini

cat composer.json 
{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "php": ">=7.0.0",
        "barryvdh/laravel-debugbar": "^3.1",
        "fideloper/proxy": "~3.3",
        "laravel/framework": "5.5.*",
        "laravel/tinker": "~1.0"
    },
    "require-dev": {
        "filp/whoops": "~2.0",
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "~1.0",
        "phpunit/phpunit": "~6.0"
    },
    "autoload": {
        "classmap": [
            "database/seeds",
            "database/factories"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "extra": {
        "laravel": {
            "dont-discover": [
            ]
        }
    },
    "scripts": {
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate"
        ],
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover"
        ]
    },
    "config": {
        "preferred-install": "dist",
        "sort-packages": true,
        "optimize-autoloader": true
    }
}

thanks

[alcohol]

No the latest stable release for Composer is 1.5.5. Even running composer diagnose tells you this.

Simply run composer self-update.

[alcohol]

Can you also return the output of:

head -1 $(which composer)

[StepanyanAlbert]

The problem is composer version?
``` head -1 $(which composer)

!/usr/bin/env php

```
I am running on VDS and not sure about version update as it may cause some troubles

[alcohol]

What does the following return?

/usr/bin/env php --version

[StepanyanAlbert]

/usr/bin/env php --version PHP 7.0.26 (cli) (built: Dec 4 2017 16:05:39) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

[alcohol]

Ok, well then I cannot help you any further. It makes no sense that Composer would detect a different version based on the information you provided us. So either you have not been entirely truthful, or your environment is seriously broken.

[StepanyanAlbert]

You serious ?
what you mean by I am not entirely truthful ?
If you are willing I will share screen to demonstrate . Environment is not broken we have 10+ laravel websites running on server (all below 5.5 version)

[alcohol]

I mean that either the information presented above has been altered for some reason (privacy or security being common ones -- people assume details are not important when they, in fact, are), or your system is just broken. Like I said before, it makes no sense for Composer to detect a different php version if all of the information provided above is accurate.

[StepanyanAlbert]

Basically that is the reason why I opened issue
assuming I will find clue .
I can confirm I have provided all information without skipping any details .
Never faced with this problem before .
IT can be because of composer version as you said but not sure update wil help and not destroy other websites

[curry684]

IT can be because of composer version as you said but not sure update wil help and not destroy other websites

Do they invoke Composer on a daily basis? No.

Please update Composer to something we actually can support, and then provide the output of composer show -p.

[StepanyanAlbert]

Thanks for reply, I will see if we can update version and get you back .

[StepanyanAlbert]

composer --version
Composer version 1.5.6 2017-12-18 12:09:18

Getting same output

composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - This package requires php >=7.0.0 but your PHP version (5.6.32) does not satisfy that requirement.
  Problem 2
    - Installation request for barryvdh/laravel-debugbar ^3.1 -> satisfiable by barryvdh/laravel-debugbar[v3.1.0].
    - barryvdh/laravel-debugbar v3.1.0 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
  Problem 3
    - laravel/framework v5.5.9 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.8 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.7 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.6 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.5 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.4 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.3 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.26 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.25 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.24 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.23 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.22 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.21 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.20 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.2 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.19 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.18 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.17 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.16 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.15 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.14 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.13 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.12 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.11 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.10 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.1 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - laravel/framework v5.5.0 requires php >=7.0 -> your PHP version (5.6.32) does not satisfy that requirement.
    - Installation request for laravel/framework 5.5.* -> satisfiable by laravel/framework[v5.5.0, v5.5.1, v5.5.10, v5.5.11, v5.5.12, v5.5.13, v5.5.14, v5.5.15, v5.5.16, v5.5.17, v5.5.18, v5.5.19, v5.5.2, v5.5.20, v5.5.21, v5.5.22, v5.5.23, v5.5.24, v5.5.25, v5.5.26, v5.5.3, v5.5.4, v5.5.5, v5.5.6, v5.5.7, v5.5.8, v5.5.9].

[alcohol]

I am not confident that updating the Composer version will fix anything. I really think cPanel is doing something weird. There is no reason for Composer to detect another PHP version, unless it is specifically running through another version.

[StepanyanAlbert]

It is awkward
running

composer show -p
composer-plugin-api 1.1.0    The Composer Plugin API
ext-bcmath          0        The bcmath PHP extension (actual version: )
ext-calendar        0        The calendar PHP extension (actual version: )
ext-ctype           0        The ctype PHP extension (actual version: )
ext-curl            0        The curl PHP extension (actual version: )
ext-date            5.6.32   The date PHP extension
ext-dom             20031129 The dom PHP extension
ext-ereg            0        The ereg PHP extension (actual version: )
ext-fileinfo        1.0.5    The fileinfo PHP extension
ext-filter          0.11.0   The filter PHP extension
ext-ftp             0        The ftp PHP extension (actual version: )
ext-gd              0        The gd PHP extension (actual version: )
ext-hash            1.0      The hash PHP extension
ext-iconv           0        The iconv PHP extension (actual version: )
ext-imap            0        The imap PHP extension (actual version: )
ext-json            1.2.1    The json PHP extension
ext-libxml          0        The libxml PHP extension (actual version: )
ext-mbstring        0        The mbstring PHP extension (actual version: )
ext-mcrypt          0        The mcrypt PHP extension (actual version: )
ext-mhash           0        The mhash PHP extension (actual version: )
ext-mysql           1.0      The mysql PHP extension
ext-mysqli          0.1      The mysqli PHP extension
ext-mysqlnd         0        The mysqlnd PHP extension (actual version: mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $)
ext-openssl         0        The openssl PHP extension (actual version: )
ext-pcntl           0        The pcntl PHP extension (actual version: )
ext-pcre            0        The pcre PHP extension (actual version: )
ext-PDO             1.0.4dev The PDO PHP extension
ext-pdo_mysql       1.0.2    The pdo_mysql PHP extension
ext-pdo_sqlite      1.0.1    The pdo_sqlite PHP extension
ext-Phar            2.0.2    The Phar PHP extension
ext-posix           0        The posix PHP extension (actual version: )
ext-readline        5.6.32   The readline PHP extension
ext-Reflection      0        The Reflection PHP extension (actual version: $Id: 5f15287237d5f78d75b19c26915aa7bd83dee8b8 $)
ext-session         0        The session PHP extension (actual version: )
ext-SimpleXML       0.1      The SimpleXML PHP extension
ext-soap            0        The soap PHP extension (actual version: )
ext-sockets         0        The sockets PHP extension (actual version: )
ext-SPL             0.2      The SPL PHP extension
ext-sqlite3         0.7-dev  The sqlite3 PHP extension
ext-tidy            2.0      The tidy PHP extension
ext-tokenizer       0.1      The tokenizer PHP extension
ext-wddx            0        The wddx PHP extension (actual version: )
ext-xml             0        The xml PHP extension (actual version: )
ext-xmlreader       0.1      The xmlreader PHP extension
ext-xmlwriter       0.1      The xmlwriter PHP extension
ext-xsl             0.1      The xsl PHP extension
ext-zlib            2.0      The zlib PHP extension
lib-curl            7.57.0   The curl PHP library
lib-iconv           2.12     The iconv PHP library
lib-libxml          2.7.6    The libxml PHP library
lib-openssl         1.0.2.13 OpenSSL 1.0.2m  2 Nov 2017
lib-pcre            8.38     The pcre PHP library
lib-xsl             1.1.26   The xsl PHP library
php                 5.6.32   The PHP interpreter
php-64bit           5.6.32   The PHP interpreter, 64bit
php-ipv6            5.6.32   The PHP interpreter, with IPv6 support

but

php -v
ea-php-cli Copyright 2017 cPanel, Inc.
PHP 7.0.26 (cli) (built: Dec  4 2017 16:05:39) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

[alcohol]

What about

type composer

[StepanyanAlbert]

type composer
composer is hashed (/usr/local/bin/composer)

Have you noticed those in last comment ?

php                 5.6.32   The PHP interpreter
php-64bit           5.6.32   The PHP interpreter, 64bit
php-ipv6            5.6.32   The PHP interpreter, with IPv6 support

I guess that explains why it does not work , but not sure how it gets it

[alcohol]

Yes, I noticed. All signs indicate your host/environment is in a completely broken state. However none of my attempts to figure out why this is the case have proven fruitful. All of the commands I gave you to run, returned output that would suggest it should just work. Quite a puzzle.

[StepanyanAlbert]

I am trying to figure out how does the composer choose an interpreter to work with ?
Can I set it manually ?

[StepanyanAlbert]

And as I said before this came out after laravel 5.5 . there are websites running 5.2-3 without problems

[johnstevenson]

Have you read the cpanel docs regarding what it does with php versions: https://documentation.cpanel.net/display/EA4/EasyApache+4+and+the+ea-php-cli+Package

The following may help:

To determine which PHP version to use, the PHP executable checks the AddType directive in the local .htaccess file. The directive may resemble the following example:
AddType application/x-httpd-ea-php54

Or there could be directives in a ea_php_yaml file. There looks likes there are plenty of ways to (mis)configure this.

[sumanta-ghosh]

I also face the same problem:

[curry684]

Try /usr/bin/env php -v, and doublecheck platform config settings.

[sumanta-ghosh]

@curry684

[curry684]

I would recommend taking up the issue with cPanel support. Nothing we can do about this from the Composer end, it's a *nix level configuration issue.

[vishalanil12]

I also face the same issue , the server doesn't have cpanel, has both php70 and php71 running on the server. Composer version is one of the latest.

[alcohol]

The composer/composer docker image is not maintained by Composer. It is a community image which has been deprecated in favor of composer.

[stof]

@vishalanil12 if you use a docker container, what is important is the PHP runtime inside the container (as that's the one running composer)

[vishalanil12]

alright, thanks

[raknjak]

It's not broken, it's a cPanel specific situation. Dissing people for using cPanel? Quite childish.
If you want a brute solution to fix your problem fast without going through the whole process of trying to find a solution that may or may not exist try
composer update --ignore-platform-reqs
This may cause other issues though, but I got mine working like this.

[alcohol]

Dissing people for using cPanel? Quite childish.

Zero people were "dissed". cPanel is notoriously bad software. While it is super convenient for people who have zero knowledge of operating servers or a linux distro, it completely hides implementation details and makes scenarios such as these virtually impossible to properly debug.

[jonasdumas]

I got same problem. I've PHP 7.2.7 running with MAMP PRO and got this error :
this package requires php ^7.1.3 but your PHP version (5.6.30) does not satisfy that requirement.

[xabbuh]

Are you sure that you did not configure this PHP version in your composer.json file using the platform key?

[tonix-tuft]

Same problem when I tried to install spatie/pdf-to-text:

- spatie/pdf-to-text 1.1.0 requires php ^7.0 -> your PHP version (5.6.30) does not satisfy that requirement.

/usr/bin/env php -v
PHP 7.0.22 (cli) (built: Aug 17 2017 11:29:35) ( NTS )
using PHP 7.0.22 on MAMP and no platform key within the `composer.json` file in my project.

Guess what, maybe someone of you uses composer through grunt within a watch task as a daemon process, like me.

I discovered that when the command is executed as a "daemonized" grunt watch process, the $PATH variable is not the same as the one I have with my user.
In fact, when the watch task runs composer, the #!/usr/bin/env php PHP interpreter resolves
to version 5.6.3 on my machine.

Hope this helps someone!

[tonix-tuft]

Anyway, I managed to resolve the problem by modifying the daemon script that I use and adding the following lines which source my user's env variables:

...
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin:${PATH} # default

# custom line, will modify $PATH to mirror my user's environment. Within .bash_profile I set the order of my $PATH variable so that `/usr/bin/env php` will match the actual version 7.0.22 which I use with my user.
. /Users/myuser/.bash_profile
...

In case someone is interested (I am not here to promote my repo, I just wanted to help), I created a repo called Grunt Hub Automator which basically allows you to perform watch tasks on multiple projects, each having its own Gruntfile.js configuration. I use it, as I said, to set up a daemon which watches my projects and uses the composer command to update and install new packages automatically whenever I update the composer.json file of one of my projects.

[purplespider]

Having this exact same issue. Such as a shame to hear about the stubbornness above.

Another workaround is to do:
php -ea_php 71 /opt/cpanel/composer/bin/composer install

This works as expected but unfortunately makes it trickier when running composer in a script as it can't dynamically detect the PHP version.

[johnstevenson]

@purplespider There is absolutely no stubbornness on our part. We would love to see a fix for this issue, but it has nothing to do with Composer.

It is clearly a configuration issue and without knowing how you or cpanel have set things up, there is not much we can do.

Why don't you ask the cpanel folks the best way of using a particular version of php with composer (so it can be used with composer ...)? Then post the solution here.

[curry684]

Whenever a case like this occurs, first run the following command:

php -v

This command cannot lie. It shows the default PHP CLI interpreter configured by your system. If it shows 5.6.30 - that's the default PHP version of your system that Composer is also bound to automatically. Fix your system, it's not Composer's fault.

If that command does show a different version than what your error shows, run this in your project folder:

composer show -p | grep php

This command will show 1 or 2 important things: the currently installed CLI version, and the actual working version of your project, as possibly overridden. If you have an issue in your composer.json this will show up here:

php                 1.2.3    Package overridden via config.platform (actual: 7.2.6)
php-64bit           1.2.3    Package overridden via config.platform (actual: 7.2.6)
php-ipv6            1.2.3    Package overridden via config.platform (actual: 7.2.6)

On a well configured system the output of these 2 commands would be something like:

curry:~$ php -v
PHP 7.2.6-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Jun 11 2018 15:00:28) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.6-1+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
curry:~$ composer show -p | grep php
php                 7.2.6    The PHP interpreter
php-64bit           7.2.6    The PHP interpreter, 64bit
php-ipv6            7.2.6    The PHP interpreter, with IPv6 support
curry:~$

Which indicates in this case beyond a doubt that 7.2.6 is the working version of Composer.

As mentioned above there is no stubbornness involved on the Composer team, it is just simply a case of local system configuration. You cannot blame Composer for not being able to install packages if you killed your network. Just like you cannot blame Composer for not being able to recognize a PHP executable it was not configured by the system to run.

[purplespider]

The problem is that on a cPanel server, Easy Apache’s ea-php-cli makes it possible to set different versions of PHP for different directories. (See here: https://confluence1.cpanel.net/plugins/servlet/mobile?contentId=2435150#content/view/2435150 )

And that while php calls the correct version, composer is unable to correctly identify the correct version for the current directory, so defaults to the server’s default PHP version.

This is what I get on a site/directory set to use PHP 7.1:

````
$ php -v
ea-php-cli Copyright 2017 cPanel, Inc.
PHP 7.1.20 (cli) (built: Jul 30 2018 09:39:58) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright © 1998-2018 Zend Technologies

$ composer show -p | grep php
php 5.6.37 The PHP interpreter
php-64bit 5.6.37 The PHP interpreter, 64bit
php-ipv6 5.6.37 The PHP interpreter, with IPv6 support
````

[MartinMekhaiel]

im having the same issue with mamp pro on a mac:

$ php -v

PHP 7.2.1 (cli) (built: Jan 15 2018 12:20:50) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2017 Zend Technologies
with Xdebug v2.6.0beta1, Copyright (c) 2002-2017, by Derick Rethans

$ composer show -p | grep php

php 5.6.30 The PHP interpreter
php-64bit 5.6.30 The PHP interpreter, 64bit
php-ipv6 5.6.30 The PHP interpreter, with IPv6 support

[johnstevenson]

And that while php calls the correct version, composer is unable to correctly identify the correct version for the current directory, so defaults to the server’s default PHP version.

Which indicates a misconfigured setup. The composer.phar script is called by php, so your command composer is pointing to the default version, rather than the one you want.

[curry684]

composer is unable to correctly identify the correct version for the current directory

Composer, like any PHP script, does not and can not care about system configuration for any directory. Composer is executed by the PHP executable, not the other way around. Composer just asks its host process what version it is, by using the documented method as you can see in the actual code.

Again, you cannot blame a script, be it Composer or any other, for the system's selection of the executable it's being run with. That's the system's job. Composer is run by PHP, not the other way around. The system is being configured by cPanel. It's therefore beyond any possible doubt cPanel's problem to fix.

[purplespider]

Which indicates a misconfigured setup.

This is not a misconfigured setup. It may be an "untraditional" setup, but it's now a very common setup on cPanel servers.

you cannot blame a script

I'm not blaming composer at all. Simply asking them nicely, to consider adding support for detecting the PHP version on servers where it's set by ea-php-cli.

I can happily run other scripts just with php ./myscript.php and it uses the correct PHP version.

[curry684]

We'd love to consider it. It's just blatantly impossible.

[purplespider]

Composer just asks its host process what version it is, by using the documented method as you can see in the actual code.

So, Composer is getting the PHP version using PHP_VERSION. I just created a script to display PHP_VERSION and ran it using php ./version.php, it correctly picked up the appropriate version of PHP for that directory (7.1).

So it must be something to do with Composer running globally, rather than from within the current working directory? So it detects the default version of PHP on the server (5.6), rather than the PHP version for the working directory (7.1 in my case). Does this sound about right?

[purplespider]

I THINK I'VE CRACKED IT!

My last post got me thinking, I've discovered you can specify a custom working directory to composer, and if you just specify the currect directory it seems to correctly detect the directory's PHP version! e.g.

composer install -d .

This ends up running composer and it correctly picks up the PHP version set by (cPanel's MultiPHP) as 7.1, not 5.6. :)

````
$ php -v
ea-php-cli Copyright 2017 cPanel, Inc.
PHP 7.1.20 (cli) (built: Jul 30 2018 09:39:58) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

$ composer show -p -d . | grep php
php 7.1.20 The PHP interpreter
php-64bit 7.1.20 The PHP interpreter, 64bit
php-ipv6 7.1.20 The PHP interpreter, with IPv6 support
````

[curry684]

If the directory is leading, and Composer is installed in its usual location of /usr/local/bin/composer, it does make sense that cPanel does not select the right executable. You could possibly work around this by symlinking, ie. run this in the project folder:

ln -s `which composer` composer
./composer show -p | grep php

Or, of course, if the PHP executable is selected correctly when not running it via env, just use:

php `which composer` show -p | grep php

If that shows the "right" PHP version you can also make it transparent:

alias composer='php `which composer`'

And permanent:

echo "alias composer='php `which composer`'" >> ~/.bashrc

[purplespider]

Thanks @curry684, your first suggestion there does seem to work!

So we have 2 decent work arounds here:

composer install -d .

or

ln -s `which composer` composer
then ./composer install

[purplespider]

Dare I ask if there is a particular reason why composer install and composer install -d . don't just do the same thing?

[curry684]

Because my/project/composer install and my/project/composer install -d . are different commands. Also see my edits to previous post, you can likely hide it completely if the symlink workaround works.

[purplespider]

Because my/project/composer install and my/project/composer install -d . are different commands.

Yes, but as per your manual:

--working-dir (-d): If specified, use the given directory as working directory.

So, if not specified, the working directory will be the current directory, correct?
And if specified as . then this also means to use the current directory, correct?

So why different outcomes?

[curry684]

Hate to be repeating myself, but that is only possible on a wildly misconfigured system. Hence my comment that they are different commands, you'd just logically expect the same output on a sane system, and something in cPanel is intervening.

But that's the recurring theme here - all the workarounds I posted cannot make a difference on a sane system, and the fact that they do only prove what a mess cPanel and/or the ea-php wrappers are making of it.

[purplespider]

Hate to be repeating myself, but that is only possible on a wildly misconfigured system.

I hate to be repeating myself too, but it is NOT a misconfigured system. cPanel's ea-php-cli package adds the ability to be able to have different PHP versions in different directories. It's clearly explained here: https://confluence1.cpanel.net/plugins/servlet/mobile?contentId=2435150#content/view/2435150

And I believe we largely got to the bottom of why composer isn't working nicely with it. I don't see it as either composer's fault or cPanel's fault.

I'm happy with the workarounds for now, but very disappointed in the unnecessary cPanel bashing.

[curry684]

The fact that the tool is documented hardly makes its behavior suddenly normal or acceptable. It's breaking sane and expected default system behavior. So yes, to us it's also frustrating to have people complaining that a PHP tool is no longer being run by the logically expected PHP executable because they knowingly installed a tool that is explicitly and only intended to change the PHP executable used based on arbitrary local environment settings and the execution path of the code.

I have helped to the best of my ability in suggesting workarounds for the issues arising from using said tool, they are confirmed to be working, and I will therefore henceforth consider this issue permanently solved and closed, and no longer respond.

[stof]

One idea I see for the different ea-php-cli behavior could be that it does not only look at the script being run (composer is in the same location in both cases) but to all arguments passed to PHP to determine the folder. In you second command, the . argument refers to a folder inside your project, and so this could trigger using the project-level config rather than the default one.

But anyway, this whole ea-php-cli thing is the culprit: it is incompatible with PHP CLI tools installed globally (as is probably the case for composer in your setup) which are meant to be used by projects (as it looks at the location of composer).

In any case, that is not something composer can solve, as composer is not selecting the PHP runtime. Your system does . The shebang tells the system to use /usr/bin/env php, and in your case, that executable is the ea-php-cli one making its magic, but the magic fails for you. That's an ea-php-cli issue.

[stof]

I confirm my idea about the fact that . references a path. I looked at the ea-php code, and they use the last path present in the arguments to determine the PHP version:
https://github.com/CpanelInc/php-cli/blob/e2331832af3a9c61d79a666cf0a13f6513899cbb/SOURCES/src/php-cli.c#L100-L104

Btw, this mean that php process_file.php /other/project/file.json would select the PHP version of /other/project/ too.

[curry684]

Ouch, that just reduces the exposed behavior to more or less random once you start running more complex CLI scripts that work on one or more files. I'd consider that an explicit (and pretty severe) bug on their end. It also invalidates most of the workarounds I suggested as they can still be broken by adding certain arguments.

[stof]

well, the -ea_php 71 argument wins over the file-based detection though. But this indeed does not integrate well with shebang-based usage of PHP as done for composer (and bash aliases might not be an option unless you make them per-folder too...)

[curry684]

It likely breaks most Symfony native console commands for the same reason unless you explicitly call php bin/console <command>.

[ITspirit]

I had the same issue yesterday. The reason for the "PHP 5" was a global composer setting i´ve done month before.

Check with:

composer global config -l

I assume you will find a line:

[plattform.php] 5.6.32

To get rid of them simply use:

composer config -g -e

And remove (or adjust) the config in the editor.

Hope this helps other too.

[ZLTM]

I mean that either the information presented above has been altered for some reason (privacy or security being common ones -- people assume details are not important when they, in fact, are), or your system is just broken. Like I said before, it makes no sense for Composer to detect a different php version if all of the information provided above is accurate.

Wow, great support here
If i can't do it then your problem is a lie, truly professional

[curry684]

Wow, great support here

You do realize this is an open source project with only spare time support from a number of volunteers getting paid nothing at all? Be glad there's any support at all before complaining about the quality - if enough people with your attitude show up here it won't be long before the free support is also going to find better things to do with their life.

If i can't do it then your problem is a lie, truly professional

That is not at all what he's saying. As any IT professional with any minimal kind of real world experience can tell you, users lie all the time. Just most of the time not with bad intent or consciously, by forgetting errors, or configuration changes they made, or ignoring important output and then claiming there never was any, misrepresenting their local system, or etc. etc.

In his response, @alcohol was completely correctly pointing out that the issue described was technically impossible to occur given the described circumstances. So either the description was wrong (which is not necessarily lying) or the host system was fundamentally broken.

The only unprofessional thing I see here is you whining about a professional, correct and concise response from a volunteer and insulting him and his professionality.

[alcohol]

Too much noise here. It does sound like there is some unexpected behaviour when running Composer in an environment that makes use of ea-php to configure the php version on a per directory basis. Perhaps consider opening a new issue with a descriptive reproducible scenario.

[stof]

@curry684 no, because bin/console is inside your project (and in many case, it will be the last file found in the arguments)

[Glen-Dango]

i have had this issue trying to 'quickly and simply' install laravel.. i needed composer and 2 days later still tryin to figure out how to update php 7.0 to php 7.2.. . . iam on wamp local host so dont think its a cpanel thing.
even worse composer says 'go write smething amazing' when nothing actually works... not really handy for testing purposes.

[johnstevenson]

This doesn't sound like a Composer issue. It sounds like you should be looking on the wamp forum.

However, if you are on Windows, run https://getcomposer.org/Composer-Setup.exe again and point it to the version of php you want to use.

[hiviyan]

You may want to try this.

composer config platform.php YOUR_PHP_VERSION
composer config platform.php 5.6.1

{
    "name": ".../...",
    "config": {
        "platform": {
            "php": "5.6.1"
        }
    },
    "require": {
        ...
    }
}

https://andy-carter.com/blog/composer-php-platform

[Khadime]

run this
composer install --ignore-platform-reqs

[ahmedfathi1]

Update Default php version in WHM to use latest php version .
This works for me

[Wilson-Emmanuel]

I have been having same issues on my localhost.
when I entered php -v on my command line, I saw php5.* even when my localhost and phpinfo() are showing php7.*.

To solve this issue, I edited the path environment variable and changed the path to the php7..
Unfortunately, composer still showed me same error of php version being 5., although, I was able to get php -v show me version 7 instead of version 5.

Finally, I reinstall composer using composer self-update and everything became normal.

[purplespider]

My previously discovered workaround of using composer install -d . has stopped working for me for some reason, so I've resorted to using composer install --ignore-platform-reqs for now.

[uzairjan]

i got the same problem and i solved it by going to Multi php Manager in WHM and change default php version from there to 7.1.

[curry684]

@hiviyan that is just about the worst possible solution or workaround that will actively break either Composer or the project itself in most situations.

As for the other commenters - you may be interested to note the issue was closed and therefore nobody is reading what you post unless someone accidentally opens it (like I do now).

[prabhoz]

When u r installing composer , u need select correct php path for PHP version 7