Locally when I run composer install it doesn't show anything about suggestions. In our CI environment it provides a long list of suggestions I'd like to avoid. I want to see the output of what's being loaded from cache and that kind of thing, just don't want to see this. I've been through the docs and haven't been able to figure out how to hide this.
The suggestions are (among many others)...
symfony/security-core suggests installing symfony/expression-language (For using the expression voter)
symfony/routing suggests installing symfony/expression-language (For using expression matching)
predis/predis suggests installing ext-phpiredis (Allows faster serialization and deserialization of the Redis protocol)
phpseclib/phpseclib suggests installing ext-gmp (Install the GMP (GNU Multiple Precision) extension in order to speed up arbitrary precision integer arithmetic operations.)
phpseclib/phpseclib suggests installing pear-pear/PHP_Compat (Install PHP_Compat to get phpseclib working on PHP < 4.3.3.)
patchwork/utf8 suggests installing ext-intl (Use Intl for best performance)
monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB)
How can I hide this output?
As of composer 1.6.3, there is a --no-suggest option that hides all suggestions when running composer install or composer update.
When you run composer install on a project that has a composer.lock file, it just installs the versions locked in the composer.lock file and nothing. In other words, the required packages and versions are already resolved and it's just installing it.
When you run composer install on a project with no composer.lock file, Composer will resolve the required packages and their versions and will store it in the composer.lock file before installing them. In this case, the project was not set up and you get notified about other suggested packages.
In the second case, there is no way you can hide the suggested packages list from the output (at least, at the time of writing this answer). In the first case, nothing is new, so it isn't shown at all.
The solution will be to push your composer.lock file to the server, which is a good practice after all (you don't want your production server to have other versions of the dependencies than your dev environment, newer versions might broke your site).
Since composer 1.6.3, the --no-suggest doesn't show anything about suggestions. But in composer 2, this option is deprecated, it has no effect and will break in composer 3 (see this link for more details).
Hope that will help in 2021!
Related
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 packagist.org 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 getcomposer.org/doc, 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.
Errors
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/or your minimum-stability settings.
This can be caused by a package being marked as non-stable and your requirements being "stable only. See: But these conflict with your requirements or minimum-stability
Or because of conflicts with other installed packages. See: How to identify what is preventing Composer from installing latest version of a package?.
For any other errors, check out the official Composer's Troubleshooting page.
Troubleshooting
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 - Composer error "Your PHP version does not satisfy requirements" after upgrading PHP
How to identify what is preventing Composer from installing latest version of a package?
Error:
somevendor/somepackage[v1.0.0, ..., v1.9.1] require composer-plugin-api ~[X.X]
This means that that somevendor/somepacakge requires that a specific version range of Composer to be installed.
Run composer -v and compare it to the version constraint in the error message (shown as ~X.X in the example above, but that could be something like ^1.0, or ^2.2, etc).
If your version does not match the constraint, see if you can either:
upgrade or downgrade your composer version to match the composer constraint in the error message
upgrade somevendor/somepackage so that it can work with your Composer version.
I tried to remove an abandoned package from my project but got the following warning in my shell:
Package jakub-onderka/php-console-color is abandoned, you should avoid using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should avoid using it. Use php-parallel-lint/php-console-highlighter instead.
I've already installed the new packages but the warning still continues to show. How can I get rid of this warning?
Thank you in advance!
These packages are used by nunomaduro/collision which is a Laravel dependency.
The package creator Tweeted out the issue was fixed on April 4th 2020*
Therefore, a composer update should bring in the new version of collision without the dependency and remove the warning.
Please note: These packages may also be used by other composer packages you are using so there's no guarantee this will work.
* Tweet: https://twitter.com/enunomaduro/status/1246531267023290370
One can normally find out what is depending on an outdated package with this command:
composer depends --tree jakub-onderka/php-console-color
In this case it might show something like this:
jakub-onderka/php-console-color v0.2
└──jakub-onderka/php-console-highlighter v0.4 (requires jakub-onderka/php-console-color ~0.2)
└──psy/psysh v0.9.9 (requires jakub-onderka/php-console-highlighter 0.3.*|0.4.*)
└──laravel/tinker v1.0.8 (requires psy/psysh 0.7.*|0.8.*|0.9.*)
└──your/project (requires laravel/tinker ^1.0)
Please ignore warnings until it has been removed as a package dependency from the collision package
see: https://laracasts.com/discuss/channels/laravel/jakub-onderka-package-abandoned-warnings
I've found nesbo/carbon in my vendor folder. It is a really useful library and I'm curious to know which other package I installed requires it.
How can I know this?
Lets look at composer why or composer depends command. This command shows which other packages depend on a certain package. Show usage
This is usage example
$ composer depends psr/log
symfony/debug v3.2.2 requires psr/log (~1.0)
Me and my team are working on a project that uses Composer for dependency management. There seems to be a difference in how a composer update is handled on several machines (running the same latest build version of Composer), but we can't figure out why.
When my teammate runs a composer update on a dependency it tries to remove a lot of data/nodes from the composer.lock file (like the entire dist and support nodes):
When I run the same update, it tries to re-add all those keys again:
We can't figure out why this is happening. Is this a certain setting?
Update: On further inspection, it appears that the "(dis)appearing" nodes all contain https links, could it have something to do with a (missing) SSL library or something?
It seems that one Composer prefers dist and one prefers source.
Look into ~/.composer/config.json if you defined a preferred install in any of your two composers. Or if you defined different preferred installs in the composer.json.
"config": {
"preferred-install": "dist"
}
You can force composer to use either dist or source with
composer update --prefer-dist
or
composer update --prefer-source
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.
--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup.
Trying to install the KnpGaufretteBundle in a Symfony 2.3 project, I'm having no luck. The problem is:
minimum-stability:stable (in composer.json);
the bundle I require is dev-master version still.
Reading this in the Symfony docs was frustrating:
If you know of a cool bundle or PHP library that still requires a dev
minimum stability, talk to the lead developer and convince him to tag
a stable release.
I'm not changing the minimum stability of the whole project to dev, as it would certainly make a huge mess - I mean, can't I use stable packages and dev packages side by side?
Am I missing something about composer maybe?
Edit (14 August 2013)
According to Sven's answer below, I've edited my composer.json (you can find it here) and it started to work. Anyway, this is a partial solution, because inline aliases do not work for dependencies - so in my case I'd have to specify all dependencies of "less-than-stable" packages first, and alias them one by one.
just use
"knplabs/knp-gaufrette-bundle": "dev-master#dev"
if you need the latest dev version
you can also change minimum-stability to dev and add "prefer-stable": true like this:
"minimum-stability": "dev",
"prefer-stable": true,
then composer will always try to find a stable version and if nothing found install dev, so your symfony packages will be still stable.
But in your case composer will install v0.1.4 (latest stable of knplabs/knp-gaufrette-bundle), so you need dev-master#dev anyway. prefer-stable is just a hint for you.
Have a look at aliases: http://getcomposer.org/doc/articles/aliases.md
They are supposed to allow you to address a branch (which by definition is always in development, because you can only access the latest commit) in a way that that branch should be the logical extension of a version tag.
For a yet untagged project, a proper assumed tag version would be like "0.0.0".
You should try the inline alias for the bundle.