ChatGPT解决这个技术问题 Extra ChatGPT

How to show what requires a package in Composer

My Composer has just told me that a certain package foo/bar is abandoned.

However, it's not listed in my composer.json, so therefore some other package has that as a dependency.

How can I get Composer to show me this?

For example, it might tell me that my root composer.json requires a/b, which requires c/d which in turn requires the offending foo/bar.


P
Pᴇʜ
composer show --tree

Lists your dependencies as a tree. If you pass a package name it will show the dependency tree for that package.

See documentation for more: https://getcomposer.org/doc/03-cli.md#show


That's good, but incomplete. For example, my composer is telling me there is a constraints problem with 'the requested package foo/bar' but 'composer show --tree foo/bar' says it's not found.
@joachim that's odd because it should list all installed packages incl. subpackages due to its documentation. Any possibility that the package requiring foo/bar didn't install due to constraints and therefore isn't in the tree? Would be easier to find a solution if we could see your composer.json and the full error message and a description what you tried to do.
Indeed, foo/bar won't install due to constraints. So I want to know what the hierarchy of constraints are, so I can fix the problem.
Also, I tried this with a package that's installed, and this appears to show the opposite of what I was asking about: eg 'composer show --tree symfony-cmf/routing' appears to show me what symfony-cmf/routing needs, rather than what is requesting symfony-cmf/routing.
Have a look at the prohibits command then: It tells you which packages are blocking a given package from being installed.
b
bishop

When you have the package name of a deep dependent, and you want to know to what root dependent it belongs, use composer depends.

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 0 removals
Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.
Writing lock file
Generating autoload files

$ composer depends guzzle/guzzle
aws/aws-sdk-php  2.8.31  requires  guzzle/guzzle (~3.7) 

Your comment on another answer suggested you were trying to untangle a dependency problem. Here's an example using depends to do that:

$ composer require phan/phan
Using version ^1.1 for phan/phan
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for composer/xdebug-handler (locked at 1.1.0) -> satisfiable by composer/xdebug-handler[1.1.0].
    - phan/phan 1.1.0 requires composer/xdebug-handler ^1.3 -> satisfiable by composer/xdebug-handler[1.3.0].
    - phan/phan 1.1.1 requires composer/xdebug-handler ^1.3 -> satisfiable by composer/xdebug-handler[1.3.0].
    - phan/phan 1.1.2 requires composer/xdebug-handler ^1.3 -> satisfiable by composer/xdebug-handler[1.3.0].
    - phan/phan 1.1.3 requires composer/xdebug-handler ^1.3 -> satisfiable by composer/xdebug-handler[1.3.0].
    - phan/phan 1.1.4 requires composer/xdebug-handler ^1.3 -> satisfiable by composer/xdebug-handler[1.3.0].
    - Conclusion: don't install composer/xdebug-handler 1.3.0
    - Installation request for phan/phan ^1.1 -> satisfiable by phan/phan[1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4].

Installation failed, reverting ./composer.json to its original content.

$ composer depends composer/xdebug-handler
friendsofphp/php-cs-fixer  v2.12.1  requires  composer/xdebug-handler (^1.0)

So, I wanted phan/phan, but that failed because of a version problem on composer/xdebug-handler, which is not a package I've ever asked for explicitly.

Then I ask what packages "depend" on composer/xdebug-handler and discover that friendsofphp/php-cs-fixer needs it (and I know about that package, it's a root dependent).

Then I note that phan/phan wants composer/xdebug-handler:^1.3 and (from the depends) that friendsofphp/php-cs-fixer allows me to have version 1.3. So now I just do an update:

$ composer update composer/xdebug-handler
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Updating composer/xdebug-handler (1.1.0 => 1.3.0): Loading from cache
Writing lock file
Generating autoload files

$ composer require phan/phan
Using version ^1.1 for phan/phan
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 5 installs, 0 updates, 0 removals
  - Installing sabre/event (5.0.3): Loading from cache
  - Installing microsoft/tolerant-php-parser (v0.0.15): Loading from cache
  - Installing netresearch/jsonmapper (v1.4.0): Loading from cache
  - Installing felixfbecker/advanced-json-rpc (v3.0.3): Loading from cache
  - Installing phan/phan (1.1.4): Loading from cache
phan/phan suggests installing ext-ast (Needed for parsing ASTs (unless --use-fallback-parser is used). php-ast ^0.1.5|^1.0.0 is needed.)
Writing lock file
Generating autoload files

o
okey_on

Use composer depends with the --tree option.

Example: say I want to see a tree structure of what packages depend on the doctrine/data-fixtures package up to the _root_ package.

composer depends --tree doctrine/data-fixtures

Output:

doctrine/data-fixtures 1.4.0 Data Fixtures for all Doctrine Object Managers
└──doctrine/doctrine-fixtures-bundle 3.3.0 (requires doctrine/data-fixtures ^1.3)
   └──__root__ (requires (for development) doctrine/doctrine-fixtures-bundle ^3.3)

R
Rolando Isidoro

The question has already been answered, but Composer offers, in my opinion, a more eloquent way, which hasn't been mentioned before: depends command alias why.

composer why aims to answer the "Why is this package installed?" question, instead of "Which packages depend on this package?", which I find much easier to remember.

Being an alias, the why command behaves the same as depends and both aforementioned options still apply:

--recursive (-r): Recursively resolves up to the root package;

--tree (-t): Prints the results as a nested tree, implies -r.


H
HappyDude

I don't know of a nice way to solve this but I ran into the same problem. A package I've never heard of was warning that it was abandoned. My solution was to search the composer.lock file for the abandoned package name. It will appear in require or require-dev for the package that depends on it.

In my case it was several levels, package A depended on package B that depended on abandoned package C. Once I identified what package A was then composer show --tree package/a showed the abandoned package in the tree output