Judging from the search hits in google and on crates.io (below), many people seem to think dependency graphs of rust crates are useful. Here's a recent blog post about coming to a dependency graph, from the other, manual, human luddite direction:
Doesn't build (via cargo install) for me, per below: Victim of cargo patch feature?
error: failed to compile cargo-graph v0.3.1, intermediate artifacts can be found at /tmp/cargo-installWtM0pq
Caused by:
failed to select a version for the requirement clap = "~2.11.3"
candidate versions found which didn't match: 2.33.3, 2.33.2, 2.33.1, ...
location searched: crates.io index
required by package cargo-graph v0.3.1
Installed. Made fun of its default output in my blog postβno offense intended, just as a form of hopefully constructive criticism.
I'm pretty sure there is more than what I've found and listed above.
1st question: Who is or wants to become the "heir apparent" in this fertile space?
2nd question: Who might be interested in finding a way to add configuration or flags to such a cargo plugin, in order to be able to automatically arrive at similar quality?
Adding features like:
Allowed/disallowed list of deps and/or maximum (e.g. transitive 1Β° 2Β°β¦) distance setting from root
of project/workspace.
Filtering deps by number of connections (e.g. filtering out leaf nodes that are wholly owned by another closer crate dependency.
Providing a means to group or otherwise color code crate (like I did in the above).
Distinguish between private and public (and default or non-default feature) dependencies, via edge styles or other markers (like mine above).
Any other interesting statistical/heuristic improvements to default graph output, without additional settings.
Also what about some kind of output mode flag for alternatives to graphviz dot like:
Anyone interested in working with me on this? I think I'd want "+1" or commit bit to a github hosted source tree, CI, etc. Or lacking that, maybe, I'll just fork and forget, if I can find the time? Thanks for your code under permissive license!
@cuviper pointed me at cargo-deps being worth an install. This is approaching usable (but not great IMO) if I don't use the --all-deps or any other add-more-crates type flags:
Sadly this is missing the whole hyperium-tokio-rs nexus which is important for reasons described in the blog post. Here is --depth 5 --optional-deps which becomes unwieldy as expected:
Tried again with cargo-depgraph (the other repo that looks alive). The main problem I see with the output (as well as cargo-deps) is that they use incrementing integers for node names and thus its very unfriendly for hand customization:
This is what lead me to just do itβ’ by text editor and scan of Cargo.toml files, initially. In my hand roled version, node 0 is named bodyimage (dot doesn't like '-' or '_' in the names), but then all the edge associations are intuitive.
Note in theory one could find a collision by simply removing special characters from the crate name. A better strategy for the tool would be to append an incremented integer value, in the unlikely event that a collision occurs (if and only if).
Hi! I'd be stoked to help you find your way around cargo-depgraph to implement any of the features you are missing.
One note about the the numbers in the output though: this is the output of petgraph's graphviz export and I'm not sure whether the node names are customizable. I don't exactly understand why this would complicate customization too. (are you talking about editing it by hand, or passing cargo-depgraph's output to a customization script before dot?)
If it helps, I can mirror the repository on GitHub. I'm not a huge fan of GitHub because it's closed-source and a big point of centralization in Open Source, but also haven't been super happy with the rejection of any social features (stars, reactions, ...) in sourcehut so I think for now the best solution in many cases may just be to use multiple platforms.
Do you need it to be visual? An ASCII tree can be generated by cargo tree (built-in command). IMHO it works well. It has some useful features like cargo tree -d that shows duplicate crates.
Thanks Jonas! Your hosting choice seems well reasoned. I was mostly just being a jerk about the git.sr.ht host name, which I literally assumed was either a joke or a typo when I first saw it, coming from the repository link of crates.io, your crate.
I think I could work directly with git.sr.ht, if you don't mind patch emails with long commit messages? (Old school that.)
I hadn't really looked at your code yet, but the fact that the graph is represented via petgraph means that I could offer my own tree-walker-style output mode, right?
And yes, if you look at my hand done graph's dot source code (I'll share an excerpt below), you will see that I'm customizing down at the level of individual nodes (e.g. xhtml label, colors) and edges (e.g. weights):
Yeah I use that all the time as well, because its so immediate and easy for small sub-graphs. However for the use cases I describe in the above linked blog post, I think its inferior, primarily because of the duplication (below as (*)).
Included below the whole cargo tree output. How do we tell this renderer to not assume every code block (e.g. ```) is rust?
(Thanks, corrected. I've been using txt all along. Isn't that kind of sad it can't interpret that? Also for the dot files, its best to use ruby for formatting. )
Honestly the whole email workflow thing is the feature I like least about sourcehut. I don't think I've even set up a mailing list for any of my projects there. Since I haven't set anything else up feel free to send patches to my email address from the git log, create todos with a link to your fork at https://todo.sr.ht/~jplatte/cargo-depgraph or whatever else might be convenienct for you. I'll probably set up a GitHub mirror soon and make issues from the current todos.