Is the php-psr extension installed by default (or by mistake)

Question

Is the php-psr extension installed by default (or by mistake)

stronk7 opened this issue 10 months ago · comments

Describe the bug
Recently we have bumped requirements for a project and it has started to use Symfony 7.x, more exactly the Cache component. And, while phplint is passing perfectly with PHP 7.x, for any run with PHP >= 8.0, we get the following error:

PHP Fatal error:  Declaration of Symfony\Component\Cache\CacheItem::expiresAt(?DateTimeInterface $expiration): static must be compatible with PsrExt\Cache\CacheItemInterface::expiresAt($expiration) in /home/runner/work/moodle-cs/moodle-cs/vendor/symfony/cache/CacheItem.php on line 77

Example run: https://github.com/stronk7/moodle-cs/actions/runs/7118709260

Then, looking to the list of installed extensions (wiki), I cannot see the php-psr extension there.

But, if I disable it in the workflow (workaround) using extensions: :php-psr, then the tests pass ok.

Example run: https://github.com/stronk7/moodle-cs/actions/runs/7118979626

So, apart from the apparent incompatibility between Symfony Cache 7.x and the PSR extension... and why we are (or not) linting the vendor directory... this issue is more about to clarify if the extension is correctly installed (and should be listed in the docs). Or if it's installed "by mistake", and it shouldn't.

Version

I have checked releases, and the bug exists in the latest patch version of v1 or v2.
v2
v1

Runners

GitHub Hosted
Self Hosted

Operating systems
ubuntu-latest (22.04)

PHP versions
8.0 to 8.2 (probably also 8.3)

To Reproduce
Install Symfony Cache 7.x and try PHP-linting.
Get the linting problem detailed in the description.

Expected behavior
Linting should end ok

Screenshots/Logs

failing run (because php-psr is installed by default): https://github.com/stronk7/moodle-cs/actions/runs/7118709260

Additional context

Are you willing to submit a PR?
I'm afraid, I don't know enough :-)

Connor Tumbleson · Answer 1 · Thu Dec 07 2023 03:18:32 GMT+0800 (China Standard Time)

Guess we submitted around same time - yeah I found it was added about an hour ago, with same stack as you.

#798

See here for add of -psr: shivammathur/php-ubuntu@83d1155

Caen De Silva · Answer 2 · Thu Dec 07 2023 03:19:53 GMT+0800 (China Standard Time)

Confirmed, tests running within the last hour are mass failing due to a conflict with the Symfony service-contracts extension.

Error: ] Your system is not ready to run the application.                       
                                                                                

Fix the following mandatory requirements:
=========================================

 * The package "symfony/service-contracts" conflicts with the extension "psr".
   You need to disable it in order to run this application.

Jordan Hoff · Answer 3 · Thu Dec 07 2023 03:21:58 GMT+0800 (China Standard Time)

I think this probably breaking a lot of CI builds right now 😬

Impacting our builds because of the Maatwebsite\Excel package:

PHP Fatal error:  Declaration of Maatwebsite\Excel\Cache\MemoryCache::get(string $key, mixed $default = null): mixed must be compatible with PsrExt\SimpleCache\CacheInterface::get($key, $default = <default>) in /home/runner/work/code/vendor/maatwebsite/excel/src/Cache/MemoryCache.php on line 62
PHP Fatal error:  Declaration of Monolog\Logger::emergency(Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerInterface::emergency($message, array $context = []) in /home/runner/work/code/vendor/monolog/monolog/src/Monolog/Logger.php on line 669
Error: Process completed with exit code 255.

Luke Leber · Answer 4 · Thu Dec 07 2023 03:26:46 GMT+0800 (China Standard Time)

I can confirm here from Drupal unit test builds as well.

PHP Fatal error:  Declaration of Drupal\Core\Logger\LoggerChannel::log($level, Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerTrait::log($level, $message, array $context = []) in /home/runner/work/xxx/xxx/docroot/core/lib/Drupal/Core/Logger/LoggerChannel.php on line 94

Edwin van de Pol · Answer 5 · Thu Dec 07 2023 03:32:14 GMT+0800 (China Standard Time)

Same here; Laravel 10 with PHP 8.2 failing...

PHP Fatal error:  Declaration of Monolog\Logger::emergency(Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerInterface::emergency($message, array $context = []) in /home/runner/work/dir/dir/vendor/monolog/monolog/src/Monolog/Logger.php on line 681

Felipe Elia · Answer 6 · Thu Dec 07 2023 03:33:05 GMT+0800 (China Standard Time)

Confirming that adding extensions: :php-psr fixes the problem for now:

    - name: Set PHP version
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.2'
        extensions: :php-psr <-- this line here
        tools: cs2pr
        coverage: none

Luke Leber · Answer 7 · Thu Dec 07 2023 03:37:06 GMT+0800 (China Standard Time)

Confirming that adding extensions: :php-psr fixes the problem for now:

    - name: Set PHP version
      uses: shivammathur/setup-php@v2
      with:
        php-version: '8.2'
        extensions: :php-psr <-- this line here
        tools: cs2pr
        coverage: none

Confirmed 2x FOSS 💪. I also want to call out how long this project has worked without fail so far -- almost forgot it was even there!

Jordan Hoff · Answer 8 · Thu Dec 07 2023 03:40:50 GMT+0800 (China Standard Time)

If you have extensions specified, you can append :php-psr to the existing list:

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: foo, bar, :php-psr

Rob Fonseca · Answer 9 · Thu Dec 07 2023 04:13:10 GMT+0800 (China Standard Time)

@jhoff you just saved us a bunch of time. Solution worked for me. Thanks for posting!

George Shestayev · Answer 10 · Thu Dec 07 2023 04:24:34 GMT+0800 (China Standard Time)

Confirmed it broke our CI too
Hopefully it will be fixed soon, don't want to do new version of our CI framework just to handle this

robHigginsPerf · Answer 11 · Thu Dec 07 2023 04:29:50 GMT+0800 (China Standard Time)

Broken on our builds as well, workaround works for emergencies, but a fix that avoids us having to touch every single build file across projects would be ideal.

Alan Matias · Answer 12 · Thu Dec 07 2023 04:55:10 GMT+0800 (China Standard Time)

It happened to me too and it broke all of our builds. I couldn't solve it with the suggestions above.

PHP Fatal error: Declaration of Symfony\Component\Cache\CacheItem::expiresAt(?DateTimeInterface $expiration): PHP_CodeSniffer\Autoload must be compatible with PsrExt\Cache\CacheItemInterface::expiresAt($expiration) in /vendor/symfony/cache/CacheItem.php on line 65

Edit: In fact, the suggestions above corrected the problem.

Fa Perreault · Answer 13 · Thu Dec 07 2023 05:36:25 GMT+0800 (China Standard Time)

Broke our CI as well

Daniel Ballesteros · Answer 14 · Thu Dec 07 2023 05:58:35 GMT+0800 (China Standard Time)

It broke my github actions unit tests, this error is thrown by the job:

Run vendor/bin/phpunit --coverage-clover=coverage.xml --log-junit=test-report.xml
PHPUnit 10.4.2 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.26 with Xdebug 3.3.0
Configuration: /home/runner/work/service-hub/service-hub/phpunit.xml

PHP Fatal error:  Declaration of Monolog\Logger::emergency(Stringable|string $message, array $context = []): void must be compatible with PsrExt\Log\LoggerInterface::emergency($message, array $context = []) in /home/runner/work/service-hub/service-hub/vendor/monolog/monolog/src/Monolog/Logger.php on line 681
/home/runner/work/_temp/84218305-dfe0-4b76-b04b-cdc431dc0ee5.sh: line 1:  3539 Segmentation fault      (core dumped) vendor/bin/phpunit --coverage-clover=coverage.xml --log-junit=test-report.xml
Error: Process completed with exit code 139.

I tried to add :php-psr to my extensions but it doesn't work:

- name: Setup PHP
   uses: shivammathur/setup-php@v2
   with:
      php-version: ${{ env.PHP_VERSION }}
      extensions: ${{ env.EXTENSIONS }}, :php-psr
      tools: composer, pecl
       coverage: xdebug

I'm on laravel 10 with php 8.1.26

Alejandro Celaya · Answer 15 · Thu Dec 07 2023 06:01:44 GMT+0800 (China Standard Time)

I don't think it's helpful to anyone who has subscribed to this issue to keep seeing messages from people saying how much this broke their CI.

This got enough visibility already and I'm sure it'll get a fix in a reasonable amount of time after the 0$ we pay for it. Let's give maintainer(s) some time.

Daniel Ballesteros · Answer 16 · Thu Dec 07 2023 06:06:06 GMT+0800 (China Standard Time)

My bad, adding :php-psr to my extensions fixed my issue

Caen De Silva · Answer 17 · Thu Dec 07 2023 06:40:01 GMT+0800 (China Standard Time)

I don't think it's helpful to anyone who has subscribed to this issue to keep seeing messages from people saying how much this broke their CI.

This got enough visibility already and I'm sure it'll get a fix in a reasonable amount of time after the 0$ we pay for it. Let's give maintainer(s) some time.

Agreed. Initially it's useful to know that an issue is not an isolated event, but it quickly hits a point of diminishing returns. A rollback PR (shivammathur/php-ubuntu#3) is made and is awaiting review from the maintainer, hopefully it is merged soon. Until then, we have a patch that works for now.

Shivam Mathur · Answer 18 · Thu Dec 07 2023 09:35:22 GMT+0800 (China Standard Time)

It has been reverted.

Apologies for this, The change was a bug fix for #796, but I guess I created a bigger issue.

Rob Fonseca · Answer 19 · Thu Dec 07 2023 21:43:41 GMT+0800 (China Standard Time)

@shivammathur thanks for reverting and maintaining the package! It's a thankless job but makes a whole lot of peoples lives way easier and much appreciated.

Dave Reid · Answer 20 · Thu Dec 07 2023 23:41:25 GMT+0800 (China Standard Time)

Thank you for resolving this so quickly! Would it be safe to assume that we won't be seeing any re-introduction of the PECL PSR extension anytime? IJust want to know for confidence going forward.

Shivam Mathur · Answer 21 · Fri Dec 08 2023 00:03:40 GMT+0800 (China Standard Time)

@davereid Yes, no new extensions that are enabled by default will be added to the cache moving forward.