Home » Php » php – Composer fails to resolve to installable set of packages on using "install" but not "update"

php – Composer fails to resolve to installable set of packages on using "install" but not "update"

Posted by: admin July 12, 2020 Leave a comment

Questions:

Background: I set up a new project, on my desktop machine, with Silex and set up my composer.json file with the dependencies that I need. I ran “composer.phar install” successfully on the desktop without any problems.

I switched over to my laptop to work on the project some more, cloned the git repo to the laptop, and tried to do a “composer.phar install” but received this message:

Your requirements could not be resolved to an installable set of packages.

So I did a “composer.phar update” instead, and it worked, but I did not want my composer.lock file updated.

Is anybody else having this issue? If not, can somebody please explain what I’m doing wrong?

Edit: I thought I should probably come back to this and update the question. I haven’t had this issue in quite some time. I don’t know if it’s an update to composer that has fixed it (people might have to comment to let me know if they’re still experiencing this issue) or if now that I’ve learned more about composer, I’m just doing things in a way that I don’t encounter this. Either way I’ve not seen this message in nearly a year and a half unless my package spec in composer.json was actually broken.

How to&Answers:

Hum, my guess would be that you are using a library which is based on a branch (dev-master, dev-branch-name or [email protected]), on which the maintainer would have forced a push recently (to rebase the branch for example).

Whenever possible, try to use stable branches (branches with a version which is linked to a tag (v1.0.0, 1.0.*, etc.). If you don’t know where to look at, you should look for your package on Packagist, and use a version which does not start by dev-, or uses a @dev modifier to set the minimum-stability to dev.

Of course, it is sometimes unavoidable. But in this case, you can always ask the maintainer of the library to tag a version. 🙂

My second guess would be that you have different libraries versions on your machine. Take the symfony/icu library, for example. Depending on the version of Icu that you have on your machine, and depending on the fact that you enabled or the fact that you have the intl extension installed on your machine or not, you may run into these issues.
As composer will try to match the composer.lock with your old machine, the dependencies won’t resolve as the locked packages will need a dependency that your system doesn’t have.
A simple way to fix this is simply to install the needed extension.