Cargo tree show optinal dependency when a crate is include as a dev-dependencies

[hommeabeil]

Problem

When a crate is included a normal dependency and as a dev-dependecies with different features, cargo tree always show the unified dependencies even if the resolver is set to 2 (resolver = "2 "). However, the build system properly handle the feature.

The first Cargo.toml

[package]
name = "tt"
version = "0.1.0"
edition = "2021"
resolver = "2"

[dependencies]

te = {path = "../te"}

[dev-dependencies]
te = {path = "../te", features = ["mockall"]}

The second one

[package]
name = "te"
version = "0.1.0"
edition = "2021"

[dependencies]
mockall = {version = "0.11", optional = true}

When looking at the Cargo.lock I see this for the te crate.

[[package]]
name = "te"
version = "0.1.0"
dependencies = [
 "mockall"
]

Running cargo tree yield this

tt v0.1.0 (/home/jbouchard/ws/rust/tt)
`-- te v0.1.0 (/home/jbouchard/ws/rust/te)
    |-- mockall v0.11.3
    |   |-- cfg-if v1.0.0
    |   |-- downcast v0.11.0
    |   |-- fragile v2.0.0
    |   |-- lazy_static v1.4.0
    |   |-- mockall_derive v0.11.3 (proc-macro)
    |   |   |-- cfg-if v1.0.0
    |   |   |-- proc-macro2 v1.0.47
    |   |   |   `-- unicode-ident v1.0.5
    |   |   |-- quote v1.0.21
    |   |   |   `-- proc-macro2 v1.0.47 (*)
    |   |   `-- syn v1.0.102
    |   |       |-- proc-macro2 v1.0.47 (*)
    |   |       |-- quote v1.0.21 (*)
    |   |       `-- unicode-ident v1.0.5
    |   |-- predicates v2.1.1
    |   |   |-- difflib v0.4.0
    |   |   |-- float-cmp v0.9.0
    |   |   |   `-- num-traits v0.2.15
    |   |   |       [build-dependencies]
    |   |   |       `-- autocfg v1.1.0
    |   |   |-- itertools v0.10.5
    |   |   |   `-- either v1.8.0
    |   |   |-- normalize-line-endings v0.3.0
    |   |   |-- predicates-core v1.0.3
    |   |   `-- regex v1.6.0
    |   |       |-- aho-corasick v0.7.19
    |   |       |   `-- memchr v2.5.0
    |   |       |-- memchr v2.5.0
    |   |       `-- regex-syntax v0.6.27
    |   `-- predicates-tree v1.0.5
    |       |-- predicates-core v1.0.3
    |       `-- termtree v0.2.4
    
[dev-dependencies]
`-- te v0.1.0 (/home/jbouchard/ws/rust/te) (*)

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.66.0-nightly (3ff044334 2022-10-17)
release: 1.66.0-nightly
commit-hash: 3ff044334f0567ce1481c78603aeee7211b91623
commit-date: 2022-10-17
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Debian 11 (bullseye) [64-bit]

[weihanglo]

Thank you for the report!

Have yet looked into the code, but I guess the root cause is the behaviour of merging features of normal dependencies and dev-dependencies in feature resolver v2. If you change from [dev-dependencies] to [build-dependencies] it should display correctly.

As I see it, the current implementation of cargo-tree sometimes shows the dependency graph as “after Cargo merges them to build”, but not the exact dependency graph from a user's perspective. It feels like a bug to me as well.

[hommeabeil]

Adding the dependency in the [build-dependencies] properly clean the cargo tree output. However, this is not a solution for me since I need the feature for the unit test (not only for a build script). The idea is to easily provide mock via annotation to the library consumer and to include mock library in the real application. I am not sure I would be able to achieve this via a [build-dependencies] :(

[ehuss]

This is the expected behavior for cargo tree. The default for -e is normal,build,dev, which shows the tree as-if you were running cargo test (that is, showing all dev-dependencies). If you run cargo tree -e normal,build, this will show the tree as-if you are running cargo build.

The intent is that cargo tree by default shows the entire tree of dependencies for an entire project.

[weihanglo]

The tree graph in the description shows dev-dependencies te as a duplicate, but actually it is not. The one in normal deps has no feature activated.

The intent is that cargo tree by default shows the entire tree of dependencies for an entire project.

By "the entire tree of dependencies", do you mean under a certain set of features, right?

It also seems that after feature resolution, features from normal and dev dependencies got merged and displayed in that way. Is it also an expected behaviour displaying a feature-merged dependency tree?

[weihanglo]

@hommeabeil
Apologize for not being clear. I didn't mean to recommend [build-dependencies] instead. I was just trying to prove that the bug was related to the interaction with feature resolver v2.

[ehuss]

By "the entire tree of dependencies", do you mean under a certain set of features, right?

Correct. cargo tree accepts flags like --features to set which features to add.

It also seems that after feature resolution, features from normal and dev dependencies got merged and displayed in that way. Is it also an expected behaviour displaying a feature-merged dependency tree?

Yes. When you run a command like cargo test, features of dev-dependencies are merged with normal dependencies. cargo tree is showing that unification.

I can see how it can be a little confusing that it shows a separate [dev-dependencies] section, but that's just showing which dependencies are specifically listed in the dev-dependencies section.

[weihanglo]

cargo tree is showing that unification

That's it! Thank you for the good explanation. Based on that, I totally agree with you this is expected behaviour.

I guess we might want to mention that cargo-tree displays a feature-unified dependency graph, which might not look identical to those specified in Cargo.toml, in its documentation or elsewhere.

[hommeabeil]

Ok, if this is the expected behavior. However, what is the easiest way to know which dependencies are actually include in a build ? This can be hard to filter what is actually used with unified feature coming from a dev-dependencies. Maybe this is commonly encounter. May cargo metadata is more precise on this ? Last question, as far I know the feature are registered in the Cargo.lock, which is the source for cargo tree ?

[ehuss]

what is the easiest way to know which dependencies are actually include in a build ?

What is included in a build is a complex question as it depends on a lot of factors (which command you run, which arguments you pass, which config file settings there are, environment variables, etc.). The only thing that will give you a full fidelity graph of what will be built is --unit-graph.

If you want a mostly equivalent overview of what cargo build does, then cargo tree -e normal,build is pretty close.
If you want a mostly equivalent overview of what cargo test does, then cargo tree is pretty close.

May cargo metadata is more precise on this ?

Unfortunately cargo metadata provides less information than cargo tree when it comes to features and some other things.

Last question, as far I know the feature are registered in the Cargo.lock, which is the source for cargo tree ?

For the most part, Cargo.lock doesn't know anything about features. It is constructed assuming all features are enabled everywhere for all targets for all dependency kinds. cargo tree uses the dependency graph in Cargo.lock as a starting point, and then based on the feature resolution algorithm (and target pruning and which CLI options are set) will filter out dependencies that aren't enabled (or weren't requested to be displayed in the CLI options).

[hommeabeil]

@ehuss Thanks for your answer. Indeed --unit-grah seems to properly show what I need. If cargo tree does work as expected feel free to close this issue. It would be nice if cargo tree does behave like --unit-graph, but it might not be possible. Thanks for the answer.