Question 264419 in PHP Versions Question posted in
You can find a list of all versions here.

Composer Different PHP Versions and common PSR

There are tons of answers on different PHP versions and Composer. But none seems to address my issue.

I have to switch back from PHP8 to PHP7 on my Ubuntu for a certain project.

No problem so far – I have different PHP versions installed and switching between PHP versions works easily:

update-alternatives --set php /usr/bin/php7.4
update-alternatives --set phar /usr/bin/phar7.4
update-alternatives --set phar.phar /usr/bin/phar.phar7.4

Then I run composer update in my project folder:

php7.4 /usr/bin/composer update

I get the following error when using composer:

Parse error: syntax error, unexpected '|', expecting variable (T_VARIABLE) in 
/usr/share/php/Psr/Log/LoggerInterface.php on line 30

The problem would seem to be that the PSR library is PHP8 only.

It would seem I need different /usr/share/php/ locations for my libraries – a common folder will not do the job, as the libraries in this folder will need to change with the PHP version.

I have no idea where /usr/share/php/ is configured – nor why composer uses this PSR stuff. At all. I think I need to install different composer version as well?

In reply to comments:

  • My composer version is 2.4.1
  • the "second error message" was copy/past chunk. Sorry – removed.
  • apt-cache rdepends php-psr-log lists composer among others
  • renaming /usr/share/php/Psr result into this error: Failed opening required ‘Psr/Log/autoload.php’ (include_path=’.:/usr/share/php’) in /usr/share/php/Composer/XdebugHandler/autoload.php
  • Tried to install the PSR log dependency in my project (php8.1 composer require psr/log:^1.0 --ignore-platform-req=all --no-update). Then I ran php7.4 composer update again, but still the same error with line 30.
Tags:

2

Answers


  1. 0

    Firstly, according to the Composer’s documentation:

    Composer, in its latest version, requires PHP 7.2.5 to run. A long-term-support version (2.2.x) still offers support for PHP 5.3.2+ in case you are stuck with a legacy PHP version.

    So, as long as you are on version 7.2.5 or higher, you should be good. Secondly, I also manage several projects myself where the PHP version varies. I have created some aliases in my Fish shell to ensure that I am using Composer with the correct PHP version (otherwise, it might pull the wrong dependencies), and these aliases perform the same function as what you did manually:

    alias composer5="php5.6 $(which composer)"
alias composer7="php7.4 $(which composer)"
alias composer8="php8.1 $(which composer)"

    I have never encountered problems with this approach, especially since composer is a self-contained PHAR archive and does not require any external dependencies.

    Now, regarding the issues with /usr/share/php/Psr/Log/LoggerInterface.php, this arises from the system-wide include path, causing this location to be included at runtime because package was installed when you was using PHP 8, so code is using PHP 8 features, and now, when you try to use PHP 7 and that package is pulled, it causes syntax errors.

    A quick search on the Ubuntu package database reveals that this likely comes from php-psr-log package, indicating that you probably installed some PHP packages using APT, which led to this dependency being installed. I always discourage people from installing any PHP application from a Debian package unless it’s the only PHP package/application installed (like in a container/VPS, etc.). This is always a source of significant issues. The only things you should have installed are the PHP interpreter and perhaps the composer PHAR; that’s it. Any other dependency should be a local package dependency kept in its vendor/ folder.

    Here are my recommended steps to check which PHP packages you have installed using APT:

    dpkg -l "*php*" | grep ii

    This command will only list packages that contain php word in the name (so for instance, the mediawiki package wont’s how up even if you have it), but if you see more than just PHP itself, consider removing them. Also you can check what really depends on the packages you find suspicious using apt-cache, i.e:

    apt-cache rdepends php-psr-log

    HINT you can look for packages depending on the php interpreter too.

    And if removal of these /usr/share/php/ files is not possible at the moment, there are some options I think are worth considering:

    1. tweak PHP at runtime, ensuring that /usr/share/php/ is not in your include path.
    2. Move (temporarily) these files away so it won’t be used at runtime. But that might break other packages, so careful.
    3. reinstall the packages you must have installed globally using PHP 7. That will make them still work with PHP 8 (unless there are bugs) and with PHP 7.

    But again. do not have anything installed globally.

    Login or Signup to reply.
  2. 0

    Your problem is installing Composer with apt.

    You shouldn’t do that, as it will install its own dependencies system-wide. For example, PHP is a Composer dependency, or these PSR libraries you mention in your question.

    Remove composer with the system’s package manager, and install Composer directly using these instructions.

    Do not install the PSR dependencies in your project unless you need them. For the looks of it, you don’t, it’s simply they were installed by apt.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search