cargo-tree

cargo-tree copied to clipboard

Currently, cargo-tree --all-features only resolves the features of the top-level crate and their dependencies, which may omit features from child crates. For example, chrono-0.4.0 depends on num 0.1 with default-features = false, and so:

chrono-0.4.0$ cargo tree -p num --all-features -a
num v0.1.41
[dependencies]
├── num-integer v0.1.35
│   [dependencies]
│   └── num-traits v0.1.42
├── num-iter v0.1.34
│   [dependencies]
│   ├── num-integer v0.1.35
│   │   [dependencies]
│   │   └── num-traits v0.1.42
│   └── num-traits v0.1.42
└── num-traits v0.1.42

whereas running the same command in num's workspace:

num-0.1.41$ cargo tree -p num --all-features -a
num v0.1.41 (file:///$PWD)
[dependencies]
├── num-bigint v0.1.41
[..]
├── num-complex v0.1.41
[... etc, lots more stuff ...]

My use-case for cargo-tree requires not only to resolve a single crate's dependencies, but to resolve its child dependencies from the point-of-view of (anyone that could possibly also depend on that child crate). In this case, a --all-features-recursive output would be more useful.

Sadly, --all-features-recursive would result in cycles like:

('clippy', 'v0.0.206')
('clippy_lints', 'v0.0.206')
('cargo_metadata', 'v0.5.5')
('error-chain', 'v0.11.0')
('backtrace', 'v0.3.8')
('addr2line', 'v0.6.0')
('cpp_demangle', 'v0.2.9')
('afl', 'v0.3.2')
('clap', 'v2.31.2')
('clippy', 'v0.0.206')

I imagine a similar problem could exist when resolving default-features recursively too, but I haven't yet found a live example of one.