It doesn't work with composer 2 #383

cataragak90 · 2020-10-27T09:36:45Z

Is it supposed to work with composer 2?

Jean85 · 2020-10-27T14:27:25Z

It should, are you encountering any particular issue?

Yozhef · 2020-10-27T14:53:02Z

I am currently struggling with the problem as well. When run phpstan see error:
php -d memory_limit=-1 ./vendor/bin/phpstan --error-format=checkstyle analyse -l 5 -c phpstan.neon.dist --debug

Fatal error: Uncaught OutOfBoundsException: Package "project/project" is not installed in /app/payment/bin/.phpunit/phpunit-9-0/vendor/composer/InstalledVersions.php:451
Stack trace:
#0 /app/payment/vendor/composer/package-versions-deprecated/src/PackageVersions/Versions.php(254): Composer\InstalledVersions::getPrettyVersion('platform/paymen...')
#1 /app/payment/vendor/jean85/pretty-package-versions/src/PrettyVersions.php(13): PackageVersions\Versions::getVersion('platform/paymen...')
#2 /app/payment/vendor/jean85/pretty-package-versions/src/PrettyVersions.php(23): Jean85\PrettyVersions::getVersion('platform/paymen...')
#3 /app/payment/vendor/sentry/sentry-symfony/src/DependencyInjection/Configuration.php(117): Jean85\PrettyVersions::getRootPackageVersion()
#4 /app/payment/vendor/symfony/config/Definition/Processor.php(50): Sentry\SentryBundle\DependencyInjection\Configuration->getConfigTreeBuilder()
#5 /app/payment/vendor/symfony/dependency-injection/Extension/Extension.php(111): Symfony\Component\Config\Definition\Proc in /app/payment/bin/.phpunit/phpunit-9-0/vendor/composer/InstalledVersions.php on line 451

Sentry version:

"sentry/sentry-symfony": "3.5.*",
"jean85/pretty-package-versions": "^1.5 || ^2.0",

Jean85 · 2020-10-27T15:04:05Z

@Yozhef that seems unrelated; it also seems that you're doing something strange with composer install...

@cataragak90 the CI just run successfully with Composer 2.0.2: https://github.com/getsentry/sentry-symfony/runs/1315282756?check_suite_focus=true#step:4:11 so it doesn't seem an issue on my side.

VincentLanglet · 2020-10-30T12:18:59Z

@Yozhef that seems unrelated; it also seems that you're doing something strange with composer install...

It seems related to Composer because I had to add a conflict with Composer >= 2 to fix this error.

Why do you think there is something strange with composer install ? @Jean85
It's just because we're using symfony/phpunit-bridge and phpstan is looking the vendor inside the .phpunit folder too.

Yozhef · 2020-10-30T12:28:28Z

@VincentLanglet you correctly thought the problem in PHPStan when in config autoload_files: path to Symfony/Phpunit-bridge PHPUnit.
I fixed this problem by simply removing the configuration config autoload_files in PHPStan.
In fact, the problem was not in the sentry.

Yozhef · 2020-10-30T12:32:20Z

@Jean85 I think it is possible to close Sentry supports Composer 2 - we have already started testing our project.

VincentLanglet · 2020-10-30T13:00:44Z

@VincentLanglet you correctly thought the problem in PHPStan when in config autoload_files: path to Symfony/Phpunit-bridge PHPUnit.
I fixed this problem by simply removing the configuration config autoload_files in PHPStan.
In fact, the problem was not in the sentry.

Do you require phpunit in your project ?
Because I don't. So I have to keep

    bootstrapFiles:
        - symfony/bin/.phpunit/phpunit-9.3-0/vendor/autoload.php

In order to load the phpunit classes.

So I still believe there is something wrong between Composer 2 / Sentry/symfony and the usage of pretty version.

Jean85 · 2020-10-30T21:33:29Z

Which version of jean85/pretty-package-versions are you using? And which of the underlying ocramius package too?

VincentLanglet · 2020-10-30T22:22:49Z

If I remove the composer/composer >= 2 conflict and run composer upgrade I only have

Updating composer/semver (1.7.1 => 3.2.2): Loading from cache
Updating composer/composer (1.10.16 => 2.0.4): Loading from cache

I use jean85/pretty-package-versions 1.5.1 version.
I don't have ocramius/package-version ; I have composer/package-versions-deprecated

composer why ocramius/package-versions
Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2.0 is now available and you should upgrade. See https://getcomposer.org/2
composer/package-versions-deprecated  1.11.99  replaces  ocramius/package-versions (1.11.99)  
doctrine/migrations                   3.0.1    requires  ocramius/package-versions (^1.3)     
ocramius/proxy-manager                2.7.1    requires  ocramius/package-versions (^1.5.1)

When phpunit-bridge is installing dependencies, a class InstalledVersions is in .phpunit/vendor/composer with only the dependencies needed by phpunit.
But there are none in my real vendor/composer

It seems like I'm using composer 1 for my project but phpunit is using composer 2. And then your library is believing I'm using composer 2.

Jean85 · 2020-10-31T20:34:28Z

It seems to me that you're having issues with the PHPUnit Bridge then...

Oh but you already opened symfony/symfony#38889 (and closed it too early IMHO).

Kocal · 2020-11-06T15:24:42Z

I'm having the same issue with the Sentry bundle, PHPStan and the PHPUnit bridge...

I think it could be solved by requiring "jean85/pretty-package-versions": "^1.5 || ^2.0" and removing explicit ocramius/package-versions dependency.

EDIT: Well, nope! I will wait for symfony/symfony#38889 and phpstan/phpstan#4022 to be fixed and configure the CI for using Composer 1 😅
Thanks you @ossinkine for the reproducer ❤️

niklasnatter · 2021-01-11T17:19:30Z

Hey,
just ran into this issue. Is there any workaround beside of using composer:1?

Thanks in advance!

niklasnatter · 2021-01-12T10:47:07Z

I investigated this a bit further - the error appears when adding the following configuration:

sentry:
    monolog:
        error_handler:
            enabled: true

monolog:
    handlers:
        sentry:
            type: service
            id: Sentry\Monolog\Handler

It is also somehow related to the the symfony/phpunit-bridge package; the error disappears if i remove the bin/.phpunit/phpunit-8.5-0/vendor/composer/InstalledVersions.php file in my project or remove the following code from my phpstan.neon:

parameters:
    bootstrapFiles:
        - bin/.phpunit/phpunit-8.5-0/vendor/autoload.php

alexander-schranz · 2021-01-12T12:05:12Z

The problem here is that there is now a: vendor/composer/InstalledVersions.php and a bin/.phpunit/phpunit-8.5-0/vendor/vendor/composer/InstalledVersions.php loaded and the second does overwrite the first one.

There is a workaround by override the InstalledVersions again using the following in the phpstan.neon file:

    bootstrapFiles:
        - bin/.phpunit/phpunit-8.5-0/vendor/autoload.php
        - vendor/composer/InstalledVersions.php # workaround for: https://github.com/getsentry/sentry-symfony/issues/383

VincentLanglet · 2021-01-12T12:14:52Z

@alexander-schranz Who do you think this issue should be addressed to ?

Either their could be something to improve to phpunit-bridge, either the documentation of phpstan could help to correctly use the bridge.

alexander-schranz · 2021-01-12T12:30:18Z

Not sure where this could be fixed its a combination of 3 different libraries so maybe we can get some feedback from one of there core contributers:

@composer (@Seldaek)
- require 2 different composer autoloader loses the InstalledVersion so composer could workaround this problem pushing to a global variable instead of dump a class with it as static which will override it.
@symfony phpunit-bridge (@nicolas-grekas)
- the phpunit bridge could remove the bin/.phpunit/phpunit-8.5-0/vendor/vendor/composer/InstalledVersions.php on installation not sure what composer would say about this but also did not get an error about it aslong I'm not use the composer api to get the phpunit/phpunit version.
@symfony phpstan-phpunit extension (@ondrejmirtes)
- phpstan could maybe make sure the correct "vendor/composer/InstalledVersions.php" one is loaded or document it

ondrejmirtes · 2021-01-12T12:32:13Z

In symfony/proxy-manager-bridge this was fixed by stopping using Version class and doing feature detection instead: symfony/symfony#39017

I guess a similar thing could be done in phpunit-bridge as well.

alexander-schranz · 2021-01-12T12:39:13Z

@ondrejmirtes thx for the fast response 🚀 . Sentry uses the version to get the version of itself (example). To tell there api which version of there library did the request the endpoint.

So the fix sentry could do here is adding a Version constant and don't use a composer plugin to get its installed version.

ondrejmirtes · 2021-01-12T12:42:47Z

@alexander-schranz Also what would probably help with the problem would be to get the version lazily once it's needed so that it gets out of this stack trace:

#0 /app/payment/vendor/composer/package-versions-deprecated/src/PackageVersions/Versions.php(254): Composer\InstalledVersions::getPrettyVersion('platform/paymen...')
#1 /app/payment/vendor/jean85/pretty-package-versions/src/PrettyVersions.php(13): PackageVersions\Versions::getVersion('platform/paymen...')
#2 /app/payment/vendor/jean85/pretty-package-versions/src/PrettyVersions.php(23): Jean85\PrettyVersions::getVersion('platform/paymen...')
#3 /app/payment/vendor/sentry/sentry-symfony/src/DependencyInjection/Configuration.php(117): Jean85\PrettyVersions::getRootPackageVersion()
#4 /app/payment/vendor/symfony/config/Definition/Processor.php(50): Sentry\SentryBundle\DependencyInjection\Configuration->getConfigTreeBuilder()
#5 /app/payment/vendor/symfony/dependency-injection/Extension/Extension.php(111): Symfony\Component\Config\Definition\Proc in /app/payment/bin/.phpunit/phpunit-9-0/vendor/composer/InstalledVersions.php on line 451

Seldaek · 2021-01-12T12:52:38Z

See https://github.com/composer/composer/blob/94076c0bb980af15e29a72328f7bc1a41e46776f/src/Composer/InstalledVersions.php#L174-L195

alexander-schranz · 2021-01-12T12:55:55Z

@ondrejmirtes could not find a way for it, it seems always be triggered because used at constructing and configure container services.
@Seldaek thank you also for the fast feedback. @ondrejmirtes do you think this could be something phpstan could call automatically?

ondrejmirtes · 2021-01-12T12:59:18Z

PHPStan could merge arrays from all the used Composer autoloaders, but I'd need a failing integration test similar to this one phpstan/phpstan#4047 first from someone that's experiencing this error. Thanks.

Jean85 · 2021-01-27T11:23:16Z

@ondrejmirtes any reason for not doing it yet? Can we help somehow?

Seldaek · 2021-01-27T11:27:15Z

@ondrejmirtes but it'll load an outdated ClassLoader which makes this whole fix in Composer not work if the ClassLoader does not have getRegisteredLoaders on it. So regardless it's not the best use case to test if this fix works.

ondrejmirtes · 2021-01-27T11:31:18Z

Until recently humbug/box or php-scoper combo weren't compatible with Composer v2. Also I thought that building PHAR with Composer v2 would actually make this problem worse. Because right now to bump into this problem (if I understand it correctly) you need to have two conflicting Composer v2 vendor directories. So when PHPStan is built with Composer v1, there need to be 2 additional Composer autoloaders present in order for this to be a problem, but with PHPStan built with Composer v2, it'd happen with only 1 additional autoloader.

If you need PHPStan built with Composer v2 in order to verify this fix, I can look into it again and produce the updated PHAR for phpstan/phpstan dev-master today.

Seldaek · 2021-01-27T11:39:07Z

I guess the thing is @alexander-schranz has vendor/ and bin/.phpunit/phpunit-8.5-0/vendor/ so two vendor dirs, but also bootstrapFiles: bin/.phpunit/phpunit-8.5-0/vendor/autoload.php so when running phpstan I don't know if phpstan would automatically load vendor/autoload.php, or first load the autoload.php from phpunit? But I guess if it loads both, in the wrong order, and first loaded the ClassLoader from phpstan (composer v1), then I can see how that would go bad yes. If there's a way to make sure vendor/autoload.php gets loaded before bin/.phpunit/phpunit-8.5-0/vendor/autoload.php, that would be a workaround too, but that would not confirm the fix in Composer.

ondrejmirtes · 2021-01-27T11:45:09Z

The order of loading is:

require_once vendor/autoload.php from inside PHPStan's PHAR
Preload some classes eagerly from PHPStan's PHAR
->unregister() on the autoloader from 1)
require_once autoloader in working directory - $CWD/vendor/autoload.php
require_once project's autoloader - it looks where the phpstan.phar that's executed is and tries to looks for '/../../autoload.php' from there.
->register(true) (prepend) the autoloader from 1) again.
Execute registered bootstrapFiles.

So I think this is true in the current version of PHPStan:

If there's a way to make sure vendor/autoload.php gets loaded before bin/.phpunit/phpunit-8.5-0/vendor/autoload.php, that would be a workaround too

Seldaek · 2021-01-27T11:50:25Z

Ok then I don't understand what is going on, but I also don't have all the information..

ondrejmirtes · 2021-01-27T11:53:59Z

I'll just try to build the PHAR with Composer v2 and see what happens.

ondrejmirtes · 2021-01-27T13:12:56Z

I tried building PHPStan PHAR with composer:snapshot but looks like setup-php doesn't have the latest version yet, it's on composer/composer@125f8a3. I guess we'll have to wait.

Seldaek · 2021-01-27T13:20:56Z

You can add a composer self-update --snapshot to run after setup-php is done I believe.

ondrejmirtes · 2021-01-27T13:37:04Z

@Jean85 I bumped into this problem (box-project/box#528). I guess the PHAR is now completely broken for this purpose and won't be able to find any package version.

ondrejmirtes · 2021-01-27T13:41:09Z

Alright, so I was able to work around the problem. @alexander-schranz Can you please try the latest phpstan/phpstan dev-master to see if it works? Thank you!

VincentLanglet · 2021-01-27T13:55:46Z

I don't know if it can help you but I tried on my CI

composer self-update --snapshot
Adding "composer/composer": "2.0.x-dev" in my composer.json

But I still get

PHP Fatal error:  Uncaught OutOfBoundsException: Package "jdhm/asv" is not installed in /home/runner/work/asv_sf_modx/asv_sf_modx/symfony/bin/.phpunit/phpunit-9.5-0/vendor/composer/InstalledVersions.php:444

Tried to only change phpstan/phpstan to dev-master, but it doesn't work too.

But if I do all of this:

composer self-update --snapshot
Adding "composer/composer": "2.0.x-dev" in my composer.json
Update phpstan/phpstan to dev-master

It works !!!
So I think a release for composer/composer and phpstan/phstan should solve everything

ondrejmirtes · 2021-01-27T13:57:39Z

I think these steps should work:

composer self-update --snapshot
composer dump-autoload
Update phpstan/phpstan to dev-master

This shouldn't be necessary but it probably just triggered exporting the new autoloader:

Adding "composer/composer": "2.0.x-dev" in my composer.json

alexander-schranz · 2021-01-27T14:04:01Z

@ondrejmirtes @Seldaek the issue is gone with the dev-master phpstan release 🎉

ondrejmirtes · 2021-01-27T14:08:30Z

Awesome, I'm happy to release PHPStan once Composer is released and setup-php GitHub action picks it up when using composer:v2 :)

Seldaek · 2021-01-27T16:12:16Z

2.0.9 is out

Jean85 · 2021-01-27T16:49:18Z

Great job everyone!

ondrejmirtes · 2021-01-27T17:11:36Z

I just released PHPStan 0.12.70 that contains the fix :) https://github.com/phpstan/phpstan/releases/tag/0.12.70

VincentLanglet · 2021-01-27T17:41:57Z

@ondrejmirtes it does not work anymore for me.

e238668648be5ff3225875c39346bd9a16f5438b was working
but 0.12.70 does not.

alexander-schranz · 2021-01-27T18:09:50Z

For me it still works.

I did:

composer self-update --2 # did get the new 2.0.9
# removed the old autoloader files
rm -rf vendor
rm -rf bin/.phpunit

composer update phpstan/phpstan # to get phpstan 0.12.70 and in this case also the new autoloader

bin/phpunit install # generate the phpunit autoloader
vendor/bin/phpstan analyse # no errors did appear

@VincentLanglet did you in your case reinstall the dependencies so both autoloaders are also reinstalled?

VincentLanglet · 2021-01-27T18:44:25Z

I think I had some weird issue with my CI, it's fixed now :)

ondrejmirtes · 2021-01-28T17:07:16Z

And now the fun starts... phpstan/phpstan#4453 I hope it can be solved by the steps I've written there...

Jean85 added the support label Oct 27, 2020

This was referenced Oct 29, 2020

Upgrading from Phpunit 9.3 to 9.4 cause weird issue with Phpstan. sebastianbergmann/phpunit#4500

Closed

Issue with phpunit 9.4 phpstan/phpstan#4022

Closed

[Symfony/Phpunit-bridge] Issue with phpstan symfony/symfony#38889

Closed

ste93cry added Type: Question and removed support labels Nov 7, 2020

j0k3r mentioned this issue Nov 16, 2020

Trying to solve the mysterious PHPStan bug j0k3r/banditore#428

Merged

alexander-schranz mentioned this issue Jan 11, 2021

Support Composer 2 natively Jean85/pretty-package-versions#14

Closed

chrisp-github mentioned this issue Jan 29, 2021

deps: require PHPStan v0.12.70 larastan/larastan#774

Merged

3 tasks

EtienneBruines mentioned this issue Feb 2, 2021

OutOfBoundsException due to InstalledVersions from .phar phpstan/phpstan#4482

Closed

johanehnberg mentioned this issue May 25, 2021

OutOfBoundsException Package "sentry/sentry" is not installed getsentry/sentry-laravel#491

Closed

It doesn't work with composer 2 #383

It doesn't work with composer 2 #383

Comments

cataragak90 commented Oct 27, 2020

Jean85 commented Oct 27, 2020

Yozhef commented Oct 27, 2020 • edited

Jean85 commented Oct 27, 2020

VincentLanglet commented Oct 30, 2020

Yozhef commented Oct 30, 2020

Yozhef commented Oct 30, 2020

VincentLanglet commented Oct 30, 2020

Jean85 commented Oct 30, 2020

VincentLanglet commented Oct 30, 2020

Jean85 commented Oct 31, 2020

Kocal commented Nov 6, 2020 • edited

niklasnatter commented Jan 11, 2021

niklasnatter commented Jan 12, 2021 • edited

alexander-schranz commented Jan 12, 2021 • edited

VincentLanglet commented Jan 12, 2021

alexander-schranz commented Jan 12, 2021

ondrejmirtes commented Jan 12, 2021

alexander-schranz commented Jan 12, 2021 • edited

ondrejmirtes commented Jan 12, 2021

Seldaek commented Jan 12, 2021

alexander-schranz commented Jan 12, 2021

ondrejmirtes commented Jan 12, 2021

Jean85 commented Jan 27, 2021

Seldaek commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

Seldaek commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

Seldaek commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

Seldaek commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

VincentLanglet commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021 • edited

alexander-schranz commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

Seldaek commented Jan 27, 2021

Jean85 commented Jan 27, 2021

ondrejmirtes commented Jan 27, 2021

VincentLanglet commented Jan 27, 2021

alexander-schranz commented Jan 27, 2021 • edited

VincentLanglet commented Jan 27, 2021

ondrejmirtes commented Jan 28, 2021

Yozhef commented Oct 27, 2020 •

edited

Kocal commented Nov 6, 2020 •

edited

niklasnatter commented Jan 12, 2021 •

edited

alexander-schranz commented Jan 12, 2021 •

edited

alexander-schranz commented Jan 12, 2021 •

edited

ondrejmirtes commented Jan 27, 2021 •

edited

alexander-schranz commented Jan 27, 2021 •

edited