Asked  7 Months ago    Answers:  5   Viewed   31 times

I did a lot of research on the web, but did not find a documentation of the composer error log. In the discussions I found, nobody had an explanation that was consistent with the error log. For example:

  • [Support] Need explanation for "Conclusion: don't install ..."
  • Why composer says "Conclusion: don't install" when (seemingly) no obstacles are present?

I know, what composer does and can resolve issues on my own, but I often have to consult for this. Despite being quite (and unnecessarily) verbose, the composer log only gives me some hints. It does not really point out the concrete problems.

Does anyone know of a complete documentation or how to explain the reasoning behind the logs, maybe taking the above ones as an example?



Documentation of Composer can be found at, especially Troubleshooting section. Usually the dependency problems comes from misconfiguration of your composer.json and understanding Composer logs comes with experience or learning on trial and error. Documenting every possible errors out of hundreds can become quickly outdated. If you believe some specific error isn't clear enough, you can always raise a new suggestion at the Composer's GitHub page.

As suggested in linked GitHub issue, "Conclusion: don't install" message it could be related to requirements defined in minimum-stability. Another linked question could be related to Composer's bug as reported at GH-7215.


Here is a small guide explaining the common Composer's errors:

  • Can only install one of: org/package[x.y.z, X.Y.Z].

    If you see this messages, that could be the main cause of the dependency issue. It basically means that based on the Composer's dependency calculation both of these versions are required, but only one major version can be installed (you cannot have both x.y.z and X.Y.Z, unless you split your configuration for different folders). To see why these packages are required, use the composer why/depends command and adjust the dependencies accordingly.

    See: How to resolve a "Can only install one of:" conflict? & How to solve two packages requirements conflicts when running composer install?

  • Installation request for org/package2 (locked at vX.Y.Z)

    This message means that there was an installation request for org/package, however, it is locked at X.Y.Z. If the requested version is not compatible with the locked version (like a different major version), you cannot install both. This message often comes along with already mentioned "Can only install one" one. So, whenever you see "locked at", that means Composer reads your installed package version from the composer.lock file. To troubleshoot, you can use composer why/depends command to find why the package was requested and adjust the compatibility, otherwise, you may try to remove composer.lock file and start from scratch (ideally from the empty folder).

    See: Installation failed for laravel/lumen-installer: guzzlehttp/guzzle locked at 6.3.0

  • org/package1 vx.y.z conflicts with org/package2[vX.Y.Z].

    It is a similar issue as above where two packages are conflicting and you need to solve the dependency manually. Reading the whole context of the message may give you some more clues. Checking the dependency tree may also help (composer show -t).

  • conflict with your requirements or minimum-stability

    This message means as it reads, so you should check the required version and your minimum-stability settings.

    See: But these conflict with your requirements or minimum-stability

For any other errors, check out the official Composer's Troubleshooting page.


Here are more suggestions how to troubleshoot the Composer dependency issues in general:

  • Add -v/-vv/-vvv parameter to your command for more verbose output.
  • Run composer diagnose to check for common errors to help debugging problems.
  • If you seeing "locked at x.y.z" messages, it relates to packages locked in your composer.lock.
  • Test your composer.json on the empty folder.
  • Keep your composer.json to minimum.
  • Run composer show -t to see your current dependency tree.
  • Run composer show -a org/package x.y.z to check the details about the package.
  • Feel free to ask a new question at Stack Overflow.

To fully debug Composer's dependency problem, you can:

  • Analyse or modify the source code (e.g. DependencyResolver/Problem.php).
  • Run Composer under XDebug, either by the breakpoint or generating a full or partial trace file.

Useful threads explaining common errors:

  • How to resolve a "Can only install one of:" conflict?
  • composer.json fails to resolve installable set of package
  • Discover latest versions of Composer packages when dependencies are locked
  • When trying to install php-jwt facing trouble with auth0
  • Reference - "Your PHP version does not satisfy requirements" with Composer
Wednesday, March 31, 2021
answered 7 Months ago

Solution #1 - add ext-zip to your required section of composer.json:

    "require" : {
        "ext-zip": "*"

Solution #2 - install php-zip extension:


Uncomment this line in your php.ini



sudo apt-get install php-zip


sudo apt-get install php7.0-zip (make sure you typed YOUR php version, you can check your version by doing php -v command)

Then, you need to restart your web server.

sudo service apache2 restart

Wednesday, March 31, 2021
answered 7 Months ago

This issue was actually the proxy variables. While the console was picking up the changes, PHP required a system restart to pick it up. So unsetting the environment variables and restarting allowed the Composer installer to retrieve the required files. Thanks Seldaek for your recommendation to check the proxy.

Saturday, May 29, 2021
answered 5 Months ago

do you edit the correct php.ini file?

you can also set the error_log path with

hmm maybe you also should prob it with file:://D:...

Saturday, May 29, 2021
answered 5 Months ago

I answered a similar question here, but I will adapt that answer to your question.

We use requestID for this purpose - assign a request ID to each incoming (HTTP) request, at the very beginning of processing (in filter) and then log that on every log line, so you can easily grep those logs later by that ID and find all relevant lines.

If you think it is very tedious to add that ID to every log statement, then you are not alone - java logging frameworks have made it transparent with the use of Mapped Diagnostic Context (MDC) (at least log4j and logback have this).

RequestID can also work as a handy reference number, to spit out, in case of errors (as you already suggested). However, as others have commented, it is not wise to load those details to database - better use file-system. Or, the simplest approach is to just use the requestID - then you do not need to do anything special at the moment error occurs. It just helps you to locate the correct logfile and search inside that file.

How would one requestID look like?

We use the following pattern:


In consists of the following variables:

  • instanceName uniquely identifies particular JVM in particular deployment environment / .
  • currentTimeInMillis is quite self-explanatory. We chose to represent it in human-readable format "yyyyMMddHHmmssSSS", so it is easy to read request start time from it (beware: SimpleDateFormat is not thread-safe, so you need to either synchronize it or create a new one on each request).
  • counter is request counter in that particular millisecond - in the rare case you might need to generate more than one request ID in one millisecond

As you can see, the ID format has been set up in such a way that currentTimeInMillis.counter combination is guaranteed to be unique in particular JVM and the whole ID is guaranteed to be globally unique (well, not in the true sense of "global", but it is global enough for our purposes), without the need to involve database or some other central node. Also, the use of instanceName variable gives you the possibility to limit the number of log files you later need to look in to find that request.

Then, the final question: "that is fine and dandy in single-JVM solution, but how do you scale that to several JVMs, communicating over some network protocol?"

As we use Spring Remoting for our remoting purposes, we have implemented custom RemoteInvocationFactory (that takes request ID from context and saves it to RemoteInvocation attributes) and RemoteInvocationExecutor (that takes request ID from attributes and adds it to diagnostic context in the other JVM).

Not sure how you would implement it with plain-RMI or other remoting methods.

Tuesday, October 5, 2021
answered 3 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :