`cargo tree -i <package>` don't require disambiguation when multiple versions are present in the dependency tree

[Skgland]

Problem

Currently cargo tree -i <package> doesn't work when <package> is present multiple times in the dependency tree.

cargo tree -i winnow
error: specification `winnow` is ambiguous
help: re-run this command with one of the following specifications
  winnow@0.7.15
  winnow@1.0.4

cargo tree already allows -i package@<version> to be repeated in a single invocation.

e.g. (adding --depth to limit the size, but works without)

cargo tree -i winnow@1 -i winnow@0.7 --depth 1
winnow v0.7.15
└── toml v0.9.12+spec-1.1.0

winnow v1.0.4
├── toml v1.1.4+spec-1.1.0
│   [dev-dependencies]
├── toml v1.1.4+spec-1.1.0
└── toml_parser v1.1.3+spec-1.1.0

Proposed Solution

cargo tree -i <package> should behave as if each version was specified

I.e. for the winnow example above cargo tree -i winnow should act as if cargo tree -i winnow@0.7 -i winnow@1 was specified on the command line.

Notes

I find it useful to look at the inverse dependency trees of duplicate dependencies -d to see which can easily be eliminated.

I usually use cargo tree -d --depth 0 to find the list of duplicates, but cargo tree -d
without duplicates is hard to follow the dependency path and with duplicates the tree gets too large.

Basically error: specification `winnow` is ambiguous, yes it is, please show me all of them, I want to see them all.

[epage]

I have had my workflow disrupted by this from time to time as well.

Erroring on ambiguous package specifications is the default approach in cargo.

Another case where it is annoying is when you have a package exists both locally and through the registry (I see this with clap). For that case, I've wondered about "favor the local package" approach since most --package flags are intended for specifying local packages.

This case is different because it is intended for any package and the cost of doing the wrong thing is less. The main downside I can think of is if the user just wants one, how do we teach them that? The error makes that easier.

[Skgland]

If ambiguous -i <package> should continue to error, what about adding support for a wildcard spec -i <package>@*? The error message could mention this for discoverability in addition to the list of versioned specs.

Though users will probably expect this to work with other commands and that would need design.