search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.66k stars 2.41k forks source link

cargo-tree: Add more pruning options. #8105

Closed ehuss closed 1 year ago

ehuss commented 4 years ago

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 https://github.com/sfackler/cargo-tree/issues/60 and https://github.com/rust-lang/cargo/pull/8062#issuecomment-606950337. (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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 1 year ago

I think this was resolved. If anyone wants features mentioned in https://github.com/rust-lang/cargo/issues/8105#issuecomment-846336129, please file a new issue instead.