Detect build/dev-dependency status of indirect dependencies?

[elinorbgr]

This information is not in the Cargo.lock, so it would imply to actually retrieve the Cargo.toml of all dependencies to parse it I guess, but that'd be pretty nice to have:

This would allow to display build-dependencies of dependencies with the relevant color, currently they are displayed as regular dependency.

Also, this would allow to apply the dev-deps / build-deps filter to dependencies as well.

Regarding the former, when using cargo-deps in a workspace with several crates, as the Cargo.lock is unified, if I run cargo deps in a crate of the workspace that depends on an other, the dev-dependencies of that second are still shown in the graph, as if they were regular dependencies.

[mrcnski]

Thanks for writing this up. As you mention, the key part is this:

so it would imply to actually retrieve the Cargo.toml of all dependencies to parse it I guess

I would love to figure out how to do this, as having the Cargo.toml of dependencies would allow me to do some other cool stuff as well like filtering by author, license, etc. Will look into it.

[mrcnski]

So I (finally) did some research into this recently. At first I thought the cargo-metadata crate was perfect for this, as it lets us get the full dependency graph as well as root package info, however neither provides complete information about further, indirect dependencies and their kinds.

I'll look into using cargo directly, though it's a large dependency and would kill the compile time. However, we definitely need either cargo-metadata or cargo, to properly handle workspaces if nothing else.

[mrcnski]

I thought about this some more and refined my understanding of this issue.

This would allow to display build-dependencies of dependencies with the relevant color, currently they are displayed as regular dependency.

Also, this would allow to apply the dev-deps / build-deps filter to dependencies as well.

Let's say we have a crate A and a regular dependency crate B which A depends on. We are generating a dep graph for A.

1. I did some tests and found that the dev deps of B are not included among the deps of A. They are not included in A's lock file. This is because they are not necessary to build A. These should obviously not be included in the deps graph for A.
2. The build dependencies of B are included among the deps of A. However, relative to A, they are treated as regular dependencies. When building A, they are always downloaded and compiled like any other dependency. Marking them as build deps is misleading unless B is also a build dep of A.

Looking at these scenarios, it seems the current logic for marking dependency type is correct. What the dep graph is supposed to show is the nature of all dependencies in relation to A. The status of dependencies in relation to B is not relevant.

Regarding the former, when using cargo-deps in a workspace with several crates, as the Cargo.lock is unified, if I run cargo deps in a crate of the workspace that depends on an other, the dev-dependencies of that second are still shown in the graph, as if they were regular dependencies.

Yeah, this scenario should be fixed if possible. I think that getting the dependency info for workspace members through something like cargo-metadata or cargo itself, instead of manually parsing Cargo.lock, may resolve this.