Second run of the latest composer install results in error: Call to undefined method Composer\Util\Http\ProxyManager::needsTransitionWarning() about composer HOT 40 CLOSED

Also temporarily solved by downgrading.

For ploi.io users you can use this command because rollback was not available on my ploi machines:

sudo /usr/local/bin/composer self-update 2.7.2

from composer.

Please stop with the +1 it's just noise. Of course downgrading works but it's a workaround it doesn't fix anything and doesn't let you upgrade which is not a long term solution. A better workaround would be upgrading composer in your dependencies, but even better as I just wrote above is figuring out why it's in the dependencies and how to get rid of it.

from composer.

Important: Please apply the fix of @Seldaek, see #11940 (comment). My suggested solution to roll back to the previous composer version is not sustainable and only a quick fix. If you are interested in a dirty quick fix, checkout my solution below.

In my case the readme/metrics package was requiring composer itself, which lead to the deployment issues.

$ composer why composer/composer -t
composer/composer 2.7.3 Composer helps you declare, manage and install dependencies of PHP projects. It ensures you have the right stack everywhere.
└──readme/metrics 11.0.2 (requires composer/composer ^2.0)
   └──spreadly/spreadly.app (requires readme/metrics ^11.0)

@cgrisar wrote, (see comment)

I returned to composer 2.7.2 and it did the trick

I had my moments of cold sweat though...

For all other Laravel Forge user stumbling across this problem. Create a Recipe with the script /usr/local/bin/composer self-update --rollback and run it on all affected servers to rollback your Composer version.

from composer.

I concur.

Having the same issues when deploying with laravel forge.

Checked the log files and it seems there was a commit yesterday on ProxyManager?

I could still deploy yesterday

from composer.

We've received several reports of this on Laravel Forge.

In some cases, it looks like the offending package is barryvdh/laravel-ide-helper which requires composer/composer on version 2.7.0 and above. 3.0.0 no longer requires Composer itself. In others, it's older versions of nunomaduro/larastan.

Looping @barryvdh into this thread.

The composer dependency has been removed since v2.12.2, in feb 2022, so if they updated in the last 2 years, that should not be a problem.
Not really sure if I can do anything about it (now)

from composer.

I use Statamic which uses composer package under the hood.

This command fixed the issue for me:

rm -rf vendor/composer/composer && composer update composer/composer

Thanks @duncanmcclean for posting the solution here statamic/cms#9945 (comment)

from composer.

I returned to composer 2.7.2 and it did the trick.

I had my moments of cold sweat though...

from composer.

Have you tried the proposed fix in #11940 (comment)

The systemic issue imo is people requiring composer in their dependencies.. This is usually a bad idea. I'm not sure why you have it. You can run and share output of composer why composer/composer -t

Then maybe we can look at why this is there and if it could be removed.

from composer.

I also downgraded to 2.7.2 and it works again. I'm using ploi server management.

from composer.

We've received several reports of this on Laravel Forge.

In some cases, it looks like the offending package is barryvdh/laravel-ide-helper which requires composer/composer on version 2.7.0 and above. 3.0.0 no longer requires Composer itself. In others, it's older versions of nunomaduro/larastan.

Looping @barryvdh into this thread.

from composer.

Yes I'll try to work on a fix because of the amount of people affected here but I'm also on vacation this week so I'll do that when i manage.. In the meantime trying to help out from my phone.

And autoloading always from the phar is not as easy as it sounds but yes it'd be nice to be able to do that i agree. For composer/composer itself it might be doable but for dependencies of composer it gets trickier as plugins/scripts might rely on the exact version that's installed but composer might be more flexible and allow running with all versions.. I guess ideally we would autoload dependencies we are compatible with from vendor and the rest from the phar to ensure composer runs fine.

from composer.

Hmm I was looking why Laravel was doing a callback instead of a script, but it appears it might have been myself who was responsible for this change.. laravel/laravel#3699

At the time, Laravel used a 'compiled' file which included all the actual files (not just classmap) so when an update was ran, it needed to clear the compiled file. It couldn't be cleared before the update, because the vendor dir was not always available: #5066 so it was moved to post-update; laravel/laravel#3687
But this would cause a mismatch between versions in the compiled.php vs new vendor files so instead of running an artisan script, it just called the clear scripts directly (laravel/framework#12827), bypassing any compiled bootstrapping.

But Laravel doesn't use the compiled file anymore (since a very long time). It would be possible to revert the changes now probably, to just use php artisan clear-compiled. But this would require every existing app to update their application composer.json.
Alternatively, the Laravel composer scripts could be modified to not load the entire application, but would also require updates (although for the framework, which would be easier to upgrade but still would leave lots of legacy available.

From the Composer side, we could compare autoloaders before/after running the callbacks. Eg. #11948
This could still lead to issues if the application actually loads classes (because I don't think you can unload them after use), or when the application tries to use a class that is already loaded by composer, but that would not impact Composer directly.

from composer.

@Seldaek and/or @johnstevenson maybe you could spot the problem immediately?

from composer.

UPDATE: Ignore this comment, I misread the commit while reading it directly on github

I think the problem is that without any proxy set the ProxyManager::getProxyForScheme method returns null and that's why needsTransitionWarning is not defined.

So maybe just checking for null at the offending line will suffice?

https://github.com/composer/composer/blame/9f84f0c32bdf15bce9e6cf14a96dec8b2bd443c4/src/Composer/Console/Application.php#L403

from composer.

@lubikx ProxyManager::getProxyForScheme returns a RequestProxy instance, but the issue is that the ProxyManager::needsTransitionWarning() method is undefined, which should not be the case:

from composer.

Rather interesting find.

If I remove composer.lock and run the install command twice with version 2.7.3 (which basically performs update and then install from lock file), the error is no longer there even if I delete vendor directory and run install again twice from the new lock file.

So it is somehow connected to the contents of a lock file and potentially to Laravel because that's what @xolf and me are using.

@xolf can you also try?

from composer.

I'm guessing this happens because you have composer itself in the vendor dir, in an older version than 2.7.3.. So first install happens fine but second one it ends up loading an outdated ProxyManager file from vendor and that one has the new method missing?

from composer.

And if that's indeed the issue then I would think a solution is to run: rm -rf vendor/composer/composer && composer update composer/composer

Sorry so many composer in that cmd but that should ensure update can run without failure as the package is gone from vendor and then it can update it to latest.

from composer.

from composer.

@cgrisar wrote, (see comment)

I returned to composer 2.7.2 and it did the trick
I had my moments of cold sweat though...

For all other Laravel Forge user stumbling across this problem. Create a Recipe with the script /usr/local/bin/composer self-update --rollback and run it on all affected servers to rollback your Composer version.

Doesn't work for me.
I specifically need to instruct the last working version number

In my case it is /usr/local/bin/composer self-update 2.7.2

BEWARE!
Forge's schedulers updates composer on a daily basis.
You can pause the scheduler

from composer.

I'm guessing this happens because you have composer itself in the vendor dir, in an older version than 2.7.3.. So first install happens fine but second one it ends up loading an outdated ProxyManager file from vendor and that one has the new method missing?

@Seldaek, it looks like you are right, but then this is a systemic problem of the composer.

This would mean it can anytime mix different composer class versions even though it should only use what is in /usr/local/bin/composer phar.

I have tried deleting vendor/composer directory, running composer install against original lock file and it was successful.

Running composer install again after this leads to the problem described in this issue.

from composer.

+1 on rolling back to 2.7.2 makes it work again (basic ci/cd setup with chialab/php:8.2 and laravel 8 php artisan testing

from composer.

@Seldaek I apologies for the noise. Seems in our case it's an old version of larastan.

$ composer why composer/composer -t
composer/composer 2.7.2 Composer helps you declare, manage and install dependencies of PHP projects. It ensures you have the right stack everywhere.
`--nunomaduro/larastan 1.0.4 (requires composer/composer ^1.0 || ^2.0)
   `--laravel/laravel dev-main (requires (for development) nunomaduro/larastan ^1.0)

from composer.

from composer.

For all packages which were fixed and already don't require composer anymore the fix is clear: upgrade these packages to a newer version.

from composer.

@Seldaek, I still think you should treat this as an issue of the composer itself.

As seen above, the composer can appear in the vendor directory just because of other dependencies, and solving this in those packages every time is cumbersome and, in the end, not a long-term solution (it can reappear anytime).

Also, invisible problems from using different code versions and even security issues can go completely unnoticed if there is no visible error in the command itself.

I really think the correct behaviour is to not autoload classes from the composer in the vendor directory when it is running from another place.

from composer.

A short-term fix for this specific case might be to check the method exists?

            $proxyManager = ProxyManager::getInstance();
            if (method_exists($proxyManager, 'needsTransitionWarning') && $proxyManager->needsTransitionWarning()) {
                $io->writeError('');
                $io->writeError('<warning>Composer now requires separate proxy environment variables for HTTP and HTTPS requests.</warning>');
...

If you want I can PR this.

Or if it's because the order of autoloading, instantiate the proxymanager earlier?

I tried replicating it by running from source, but it doesn't seem to trigger the error then.

from composer.

Or if it's because the order of autoloading, instantiate the proxymanager earlier?

I tried replicating it by running from source, but it doesn't seem to trigger the error then.

My bad, I could replicate it. If I move the loading of the instance before the running of the command, it seems to be fixed (for this case).

Could you try #11943 ?

(So clone composer to a directory, run composer install there and try with and without my patch by running php <dir to your composer>/bin/composer install --prefer-dist --optimize-autoloader -vvv)

from composer.

Can someone please post an easy way to reproduce this with an open source repo I can clone, or a complete composer.json that just works without anything else posted here? No Laravel Forge or other stuff in the loop please.

I tried with the original post's composer.json but no luck reproducing this..

I have a feeling for how this happens and I'm sure #11943 will work around this particular instance of the problem, but I'd still like to have a conclusive way to repro so I can analyse it further later and try to find a more future proof solution.

from composer.

Composer 2.7.4 is now out which hopefully fixes it. I'd still appreciate a repro case though as per my post above.

from composer.

Can someone please post an easy way to reproduce this with an open source repo I can clone, or a complete composer.json that just works without anything else posted here? No Laravel Forge or other stuff in the loop please.

composer create-project laravel/laravel:^9 laravel9
cd laravel9
composer require nunomaduro/larastan:1.x composer/composer:2.5.x --dev
composer  install --prefer-dist --optimize-autoloader -vvv

You need a package that install composer/composer, but need an older version (eg 2.5).
(If you update to the latest versions, it doesn't happen)

from composer.

Composer 2.7.4 is now out which hopefully fixes it. I'd still appreciate a repro case though as per my post above.

Can confirm that this fixes the above test case. Thanks for the effort while you're on vacation! Hope you can enjoy the rest of it ;)

from composer.

Ah ok, yeah I tried that already but it wasn't triggering, because I was missing some script handlers.. Your example works fine if you run the last composer install with --no-scripts.

It seems the problem is that:

    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump"
        ]
    },

Calls

        require_once $event->getComposer()->getConfig()->get('vendor-dir').'/autoload.php';

To ensure that all vendor dir packages are usable in the process I guess.. and then that registers the project's autoloader, which prepends it and thus overrides Composer's native autoloader..

I don't really see a way to fix this without dirty hackery in vendor/composer/autoload_real.php, but I'll give it some more thought.

from composer.

Maybe it would be possible to sandbox the event scripts? I think you're using a separate process for php/other scripts already, so maybe you could fire of a composer command to execute callables also? Might be slower, but doesn't have any side effects on the main process probably?

from composer.

That'd for sure cause breakage tho as some php scripts are used to hook into and modify composer settings or behavior.

But I'd argue those laravel scripts running a full command would be better done as an actual command instead of php script handler.

The problem tho is preventing misuse is very difficult and even if it gets fixed old versions linger on as we saw above.. So a solution on the composer side would be nice.

from composer.

Rather interesting find.

If I remove composer.lock and run the install command twice with version 2.7.3 (which basically performs update and then install from lock file), the error is no longer there even if I delete vendor directory and run install again twice from the new lock file.

So it is somehow connected to the contents of a lock file and potentially to Laravel because that's what @xolf and me are using.

@xolf can you also try?

For me just removing the composer.lock worked fine!

from composer.

@barryvdh thanks for the idea and the help looking into this on the Laravel end, see #11955 - it's an alternative impl of the same, which I was able to validate in various conditions. For sure it's not 100% fool proof but it should help prevent most accidental issues like this one.

from composer.

How about resurrecting my previous idea about generating scoped versions of Composer that package maintainers can require?
#11884

As you may know, Drupal's new Automated updates feature highly relies on Composer therefore installs its a non-dev dependency.
https://git.drupalcode.org/project/drupal/-/blob/10.2.5/composer.json?ref_type=tags#L22

from composer.

My opinion on that hasn't changed sorry :)

Note that having composer in the deps is not really a problem in itself. It was triggering further issues in Laravel there because they include the application's autoloader in the script handler, and that case will be fixed as well. So we harden ourselves against these problems more and more as we find them, making scoping less and less needed.

from composer.

🤞 and fair enough :) and I'll keep an eye on these kinds of issues to collect ammunition for the scoped use case ;)

from composer.