Sometimes, when considering adding some crate as a dependency, I'm thinking: How would this influence my crate in the sense of how fundamental my crate appears to others. On crates.io/docs.rs, I can easily see what dependencies other dependencies use, but it is harder to quickly make a judgement on the fundamentality of some crate: Does it have a deep or a shallow dependency graph?
This got me thinking about a simple crate scoring system, call it "dependency graph height", inspired from the height property of a tree: The dependency height of my crate would be the maximum height of all my dependencies plus 1.
What I'm thinking is that having this information easily accessible on e.g. crates.io could help developers choose their dependencies in an optimal way in order to target their desired level of fundamentality for their own crates. Theoretically, over time, it could help optimizing and flattening crate depenency graphs in general.
I have not thought through any details around optional features or anything like that. I just wanted to launch the abstract idea, as I haven't seen it posted anywhere else (or I don't know what to search for). I also haven't seen this feature in package management systems of other languages.
Yes, I absolutely can use various cargo tools to extract this information. My question is more about: Would it be useful to the ecosystem if the crate graph height number was more visible? (like the listing of each crate's direct dependencies already is)
cc @kornel : metric that could be displayed on lib.rs
Of course, this isn't really a great metric, since e.g. regex used to be a single crate, but now has split its internals into separate crates for organization, so has a higher crate depth. So, naively just showing crate depth is probably not that great an idea.
There's probably a smarter way to calculate how fundamental a crate is which uses a rating system rather than just crate depth, but I don't have any ideas how it would be constructed.
I don't think this is very useful on its own. In a larger project, the more interesting metric is, "how many crates does this pull in that I don't already rely on anyway". Plus, a chain of several small dependencies might be less of a problem than if a crate pulls in several larger crates directly.
I don't think that the depth (and width) of your dependency is really important. I think that metric like "are all of your dependencies reviewed", "are the maintainers of your dependencies reactive if security issues are found", "is the performance and memory usage of your dependencies (including future versions) good enough for your use-case" much more useful, even if they are much more complicated to access. I have huge hope that cargo-crev will help with that.
Compilation time of each crate shown in crates.io can be a good enough measure (Not to mention, it has to be shown for dependencies and dependents as well)