The dependency graph "height" of a crate

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, 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. 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.


You can use cargo tree to see a tree of all your direct and indirect dependencies. For example

$ cargo tree
rustc_codegen_cranelift v0.1.0 (/home/bjorn/Projects/cg_clif)
├── ar v0.8.0 (
├── cranelift-codegen v0.82.1
│   ├── cranelift-bforest v0.82.1
│   │   └── cranelift-entity v0.82.1
│   ├── cranelift-codegen-shared v0.82.1
│   ├── cranelift-entity v0.82.1
│   ├── gimli v0.26.1
│   │   └── indexmap v1.8.0
│   │       └── hashbrown v0.11.2
│   │       [build-dependencies]
│   │       └── autocfg v1.1.0
│   ├── log v0.4.14
│   │   └── cfg-if v1.0.0
│   ├── regalloc v0.0.34
│   │   ├── log v0.4.14 (*)
│   │   ├── rustc-hash v1.1.0
│   │   └── smallvec v1.8.0
│   ├── smallvec v1.8.0
│   └── target-lexicon v0.12.3
│   [build-dependencies]
│   └── cranelift-codegen-meta v0.82.1
│       └── cranelift-codegen-shared v0.82.1
├── cranelift-frontend v0.82.1
│   ├── cranelift-codegen v0.82.1 (*)
│   ├── log v0.4.14 (*)
│   ├── smallvec v1.8.0
│   └── target-lexicon v0.12.3
├── cranelift-module v0.82.1
│   ├── anyhow v1.0.56
│   └── cranelift-codegen v0.82.1 (*)
├── cranelift-native v0.82.1
│   ├── cranelift-codegen v0.82.1 (*)
│   └── target-lexicon v0.12.3
├── cranelift-object v0.82.1
│   ├── anyhow v1.0.56
│   ├── cranelift-codegen v0.82.1 (*)
│   ├── cranelift-module v0.82.1 (*)
│   ├── log v0.4.14 (*)
│   ├── object v0.27.1
│   │   ├── crc32fast v1.3.2
│   │   │   └── cfg-if v1.0.0
│   │   ├── indexmap v1.8.0 (*)
│   │   └── memchr v2.4.1
│   └── target-lexicon v0.12.3
├── gimli v0.26.1 (*)
├── indexmap v1.8.0 (*)
├── object v0.27.1 (*)
├── once_cell v1.10.0
├── smallvec v1.8.0
└── target-lexicon v0.12.3

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

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 can be a good enough measure (Not to mention, it has to be shown for dependencies and dependents as well)