composer: Composer hangs in "Something's changed, looking at all rules again" state

“require-dev”: { “fzaninotto/faker”: “~1.4”, “mockery/mockery”: “0.9.*”, “phpunit/phpunit”: “~6.0”, “phpspec/phpspec”: “~2.1”, “doctrine/dbal”: “^2.5”, “filp/whoops”: “~2.0”

After removing the phpspec/phpspec composer update works fine.

I was able to reproduce it with this minimal composer.json

{
    "name": "smichaelsen/composer-test",
    "require": {
        "behat/behat": "~2.5",
        "friendsofphp/php-cs-fixer": "^2.12"
    }
}

Well, I guess have to decide between tested code and clean code then…

I have the exact same scenario as @windhamdavid , with the same package: https://github.com/nunomaduro/collision

I’m trying to upgrade from Laravel 6.x to 7.x and this issue is making it impossible to do so.

I resolved the conflict by updating a package at a time in order to identify the conflicting package

What was the exact Composer command you ran when you identified the conflicting package? The one you show, composer update --prefer-dist -vvv --profile, doesn’t explain how you identified the conflict.

Also, you don’t show which packages you added or removed, if any, before running composer update with a successful result.

In my case, I ran composer update ..., took the first package that failed due to being locked at a different version, and appended it to the command, ad nauseam, until I got the dreaded

Resolving dependencies through SAT
Looking at all rules.
Something's changed, looking at all rules again ...

(What has changed, exactly? The weather? This message could probably be improved…)

The only reason I knew it was nunomaduro/collision is because that’s the last package I appended to the command before I got the above message.

@windhamdavid Ultimately, it would be extremely helpful if you could answer the following:

1. What changes did you make prior to running composer update ... with the result that you show in https://github.com/composer/composer/issues/7665#issuecomment-590474507 ?
2. After receiving that output, what further changes did you make prior to running composer update ... with a successful result, i.e., how did you actually fix the problem?

@ahsanmster Yes, I managed to work around the problem by identifying the offending package and fixing the conflict. My apologies for not posting an update before now.

In my case, the problematic package was not nunomaduro/collision per se, but rather, another third-party package whose version of symfony/console conflicted with it, exactly as @windhamdavid describes in https://github.com/composer/composer/issues/7665#issuecomment-590474507 :

My case was the same as nunomaduro/collision#83 and nunomaduro/collision#70 in that I had packages dependencies with conflicting symfony/console versions.

The specific method that I used to identify the problematic package was as I described in the comment you quoted (although, I could have been clearer and provided an example). Essentially, the process is as follows:

1. Run composer update laravel/framework (or whichever package you’re trying to update), and it should fail due to a package being locked at a different version. (Let us know if you get the Something's changed message already, at this point!)
2. Copy the package name mentioned in the first error message in the above step (there may be many errors, but only the first one matters here) and append it to the previous command. So, if the first failure mentions the acme/foo package, the next command to run would be composer update laravel/framework acme/foo.
3. When that results in another failure of the same type, for, e.g., the acme/bar package, then run composer update laravel/framework acme/foo acme/bar and repeat the process until you get the dreaded Something's changed message. Don’t forget that you can use wildcards in package names, too, e.g., symfony/*, which can save you a lot of time if you’re dealing with many packages from the same vendor. The last package you add to the command prior to getting Something's changed should provide a clue as to the offending package that requires the conflicting version of symfony/console (or whatever it happens to be).
4. If the package is one of your own, update the dependencies in its composer.json so that the offending package, such as symfony/console, doesn’t conflict with nunomaduro/collision, for example. If the package is not your own, then I suppose you have no choice but to fork it and fix it in your fork (until it’s fixed upstream), or perhaps add something clever in your project’s top-level composer.json to alias the package version or similar to solve the conflict.

Hope that helps!

In one of these cases, I let it run on a server inside screen for a while:

Something’s changed, looking at all rules again (pass #<span></span>193) Dependency resolution completed in 344463.834 seconds Your requirements could not be resolved to an installable set of packages.

That’s a long time: Pass #<span></span>193 needed about 95 hours or four days to complete! I guess some composer internals might be not properly optimized…

PHP 7.1 + Ubuntu 16.04 (Core i7) + composer 1.7.2

My workaround for this was to remove the entire require-dev block (x7 deps) and then re-run composer update. This ran sucessfully. Once complete, I then added each dev-dep back-into composer.json one-by-one, running composer update each time. I repeated this twice to be sure.

Note: I still got the “Something’s changed” message each time, but it only ran for ~5+ passes (As opposed to hundreds), and took 2-3s.

Hope that helps someone.

Maybe the issue happens with PHP 7.2 and not with PHP 7.1? https://travis-ci.com/freshbitsweb/laratables/builds/89503447

I had this problem as well. I forced composer to stop after pass 1k+.

It turns out that it’s caused by this combination of require-dev dependencies:

    "require-dev": {
        "phpunit/phpunit": "~6.0",
        "friendsofphp/php-cs-fixer": "^2.10",
        "phpmd/phpmd" : "@stable",
        "phpdocumentor/phpdocumentor": "2.*"
    },

Removing phpdocumentor resolved the issue in my case.

I also had a similar problem today trying to update my application to Laravel 5.6 and then 5.7. In my case I had to remove phpspec/phpspec and another library that was requesting Symfony components from version 3.2 by using the following condition 3.2.*. Not sure why, but in other cases it was just raising errors immediately, and I would had expected the same scenario for this library, but it didn’t happen

I had the same issue too. I removed phpunit and phing from my composer file. I’m not sure which one was the causing the problem, or both. But it works now.

I have been trying to install https://github.com/orchestral/testbench

I temporarily removed "illuminate/support": "5.5.*|5.6.*|5.7.*" from require section and it worked. Not sure what’s happening.

Going to close this as #9312 is merged and this contains so many repro cases that it’s turned into quite a mess. If anyone still experiences the problem with the latest snapshot (composer self-update --snapshot) please open a new issue.

@tolidano Not sure how your issue is related to the bug here. But you seem to simply be looking for the “–update-with-dependencies” option on composer require. Since you have all kinds of deps locked to versions not compatible with what you’re trying to require.

@naderman the above composer.json sample indeed seems incredibly problematic. Would you be able to dive into the solver and see what the underlying cause for this is?

Currently getting this issue, removing "phpunit/phpunit": "4.1.0", fixed this for me.

"require-dev": {
     "phpunit/phpunit": "4.1.0",
     "squizlabs/php_codesniffer": "1.5.3",
     "phpmd/phpmd": "@stable",
     "pdepend/pdepend": "2.4.0",
     "fabpot/php-cs-fixer": "~1.2",
     "lusitanian/oauth": "~0.3 <=0.7.0",
     "sebastian/phpcpd": "2.0.0",
     "deployphp/recipes": "4.0"
},

I’m not sure. It would make sense if it didn’t work because of something being wrong with the package, but from what I can tell, that’s not the case at all. To start with, I would think that one of the developers should be able to explain under what circumstances this message is generated.

had the issue with php 7.1, removing phpspec/phpspec from require-dev helped me as well