cargo-tree: Add more pruning options.

[ehuss]

A large tree can be hard to look at and navigate. It would be useful if cargo-tree had more options for reducing or pruning the packages displayed. Some ideas:

depth

Add a --depth option to cargo-tree to control the depth displayed.
A numeric value would be simple, but perhaps other string options like "workspace" (limit to workspace members) would be useful.
See sfackler/cargo-tree#60 and #8062 (comment). (Or maybe --prune=non-member?)

prune

Add a --prune option which will remove a specific package (and all its dependencies). For example, --prune rustc-workspace-hack in the rustc repo.

[weihanglo]

but perhaps other string options like "workspace" (limit to workspace members) would be useful.

Maybe this feature is supposed to be in --prune or something else but not in --depth. It is quite weird for me to pass a non-numeric value to --depth option. Correct me if I mistake your instance.

[weihanglo]

Another question about --depth. When running cargo tree -e features, some dependencies show twice due to their nested features. For instance, anyhow gets a default feature listing std feature to enable, so running cargo tree will get anyhow listed twice.

[features]
default = ["std"]
std = []

$ cargo tree -e features
cargo v0.55.0 (/home/rust/cargo)
├── anyhow feature "default"
│   ├── anyhow v1.0.38
│   └── anyhow feature "std"
│       └── anyhow v1.0.38

How should --depth interact with -e features?

One way is treating feature nodes as normal dep nodes which are counted in when calculating depths. This approach is feasible but I am afraid it's not that informative and useful. To find the same dependency showing in cargo tree, people need to increase the --depth value, which makes --depth inconsistent between the existence of -e features.

The other solution I can think of is skipping all feature node, only take dep nodes into account when calculating depths. Although the meaning of --depth is consistent between -e features option again. This may make the UI more confusing since --depth not concerning display content directly.

I prefer the first to the second. The first is also trivial to implement.

[ehuss]

Yea, using a non-numeric value for --depth would probably be a little strange.

As for which behavior to use, the first is probably easier, so I would lean towards that, and then see how it goes.

The -e features flag was written with the intent to use it with the -i flag. In that case, the tree is usually pruned pretty well (it is usually a much smaller subset). I generally find the non-inverted view of -e features too noisy to read.

[weihanglo]

For pruning workspace members/non-members, I propose that adopting the other option which accepts both, member, non-member values, and we leave the --prune option simply accept SPEC. This make thing go simpler, but also lead to a new naming problem of this member-pruning option. I haven't come up with any proper name at this moment 😂

[weihanglo]

I think this was resolved. If anyone wants features mentioned in #8105 (comment), please file a new issue instead.