TBD:

• Will there be a subgraph for the workspace members by default (could be named after the parent directory for example)
• What about multiple subgraphs?
  • In general, I'm not sure whether to mirror cargo-deps' CLI for this feature

Useful for medium to large projects.

… on optional dependency edges.

With graphviz's png renderer and dot layouting, this will probably not look good, but maybe it works for other layouts.

Allow users to specify the depth of dependencies to render.

See also --direct-dependencies-only

See this commit page for discussion.

… on target-specific dependency edges.

With graphviz's png renderer and dot layouting, this will probably not look good, but maybe it works for other layouts.

This is reproduced with this repository / crate:

https://gitlab.freedesktop.org/libopenraw/libopenraw.git

(I'm the developer for that crate)

cargo-depgraph 1.6.0

$ cargo depgraph --all-deps
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
zsh: IOT instruction (core dumped)  cargo depgraph --all-deps

In gdb

Program received signal SIGSEGV, Segmentation fault.
0x000055555557c6c9 in cargo_depgraph::graph::update_node ()
(gdb) where
#0  0x000055555557c6c9 in cargo_depgraph::graph::update_node ()
#1  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#2  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#3  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#4  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#5  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#6  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#7  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#8  0x000055555557c833 in cargo_depgraph::graph::update_node ()
#9  0x000055555557c833 in cargo_depgraph::graph::update_node ()

Imported from sourcehut todos, originally reported by @vberger.

Tested on Smithay master (commit 25365ed69abbff56a9b188a37b9cd2469e2bc642).

Comparing:

• running cargo depgraph --all-deps --exclude anvil --no-default-features on the bare repo
• removing the [workspace] section in the Cargo.toml to make as if anvil did not exist, deleting Cargo.lock, and running cargo depgraph --all-deps --no-default-features

This first graph is very large and includes almost all dependencies, while the second is very small (as expected).

I suspect that even when anvil is excluded, it is still being used to resolved features, causing most of smithay's feature to be enabled even though the --no-default-features flag was passed.

At first, probably just adding a version to all crates of the same name, if there are multiple.

Later, crates could be disambiguated fully, adding even more info depending on what the crates (don't) differ in. E.g. a crate cr that is in the depgraph as a path dep once and a crates.io dep once, but both with the same version could be shown as cr [path = "../cr"] and cr [reg = "crates.io"] (leaving out the version).

Locally I wrote some code to generate the image below. This deduplicates transitive dependencies, but keeps those that 'go around' optional deps. I.e., the solid line between pa-web and pa-vis is nice because without it (the current behavior) it would seems as though a large part of the tree is optional, while in fact it's not.

Would you accept a PR for it? And in that case, what should the flag be named? I'm not sure myself. And should this be default?

Hello, I wanted to try this tool out on https://github.com/googleforgames/quilkin and running gives the following messages.

cargo depgraph --all-deps | dot -Tpng > graph.png

crate from resolve not found in packages => dependencies, this should never happen!
crate from resolve not found in packages => dependencies, this should never happen!
crate from resolve not found in packages => dependencies, this should never happen!

Hello,

The installation and first use guide is a bit hard to understand, I'm currently stuck as I don't know what "dot" is that the output of depgraph is being piped to, it's not a super easy thing to google either. It's not a recognized internal command on windows, so perhaps a brief explanation on what this is would help new users like myself?

This should not be the case.

It was removed in 1157148 because it didn't actually work.

Note: a normal dependency of a build dependency should be shown with --build-deps --no-normal-deps. A dependency that is both a dev-dependency and a regular dependency, as well as its dependencies, should be shown with --dev-deps --no-normal-deps.

The default colors and styles might not be suitable for everything, and building in support for customization shouldn't be that hard.

As a workaround until this exists, one can already alter the emitted dot code before passing it to graphviz.

TBD:

• Should it be possible to use a non-workspace crate as a root? (dev-dependencies couldn't be shown, but otherwise should not be a problem to implement)
• What should the default in a workspace with a toplevel crate be: Have all workspace members as roots, or just the toplevel crate?