libnix impact study

22 sep 2026

motivation

libnix can be added to any package manager (PM) so consider this also a direction PMs will be heading in general with libnix.

this post looks into the cargo+libnix impact, i.e. using the prototype discussed in the previous post cargo-libnix, and we use:

nixpkgs revision 1c3d5a53f03f2eb5677f6f3b34f0ef31261ba485, from Sat Dec 13 13:17:29 2025 +0000
see full details here: nixpkgs-datamining

rust & crates.io

a rust project usually uses crates.io dependencies like serde, syn and similar. these can be visualized with cargo-depgraph:

these rust libraries (rlibs) are statically compiled into the final binary but during build time they are seperate entities. especially, since cargo-libnix shares crates.io dependency builds beyond the ./target/ folder, we can check what the speedup would look like, when it would be used for building software in buildRustPackage.

`cargo` revisions in nixpkgs

cargo in nixmultiverse lists 10 to 15 revision bumps per year from 2018 to 2026 but cargo is only one gear in a huge set of dependencies, we need to study a better metric: buildRustPackage implementation changes!

`buildRustPackage` implementation changes

nixpkgs architectures

nixpkgs and buildRustPackage is used with these 4 different architectures (with different nixpkgs revision than below):

Architecture	Packages	% of total
x86_64-linux	2555	28.1%
aarch64-linux	2517	27.6%
x86_64-darwin	2008	22.0%
aarch64-darwin	2007	22.0%
Total	9087	100%

total package/architecture combinations: 9087

when changing the nix implementation of buildRustPackage, like when updating rustc/cargo or the toolchain, this can multiply the rebuild workload across the architectures.

direct and indirect dependencies of the 2312 buildRustPackage rust projects

these values were generated using cargo build --unit-graph -Z unstable-options > $out/unit-graph and the parsing of the graph is sometimes not the exact same as a cargo build but there is nothing better ATM. i verified this for a few crates and the numbers seem to match most of the time.

📊 interactive plotly graph

Project Analysis

Total Projects Analyzed: 2300
Average Internal Crates per Project: 3.8
Average Direct Dependencies per Project: 15.7
Average Transitive Dependencies per Project: 138.8

Overall Dependency Count

Total Internal Crates: 8759
Total Direct Dependencies: 36080
Total Transitive Dependencies: 319137

Total & Percentage Breakdown

Total Crates Count: 363976
Internal Crates: 2.4% of Total
Direct Dependencies: 9.9% of Total
Transitive Dependencies: 87.7% of Total
Combined Direct and Transitive Dependencies: 97.59% of Total

Direct Dependencies Distribution

median=12.0, p25=6.0, p75=21.0, p90=32.0, min=0, max=162
p75 of projects use <= 21.0 direct dependencies

Internal Crates Distribution

median=1.0, p25=1.0, p75=2.0, p90=7.0, min=1, max=257
p75 of projects use <= 2.0 main crates

finding identical crates.io dependencies in 2312 buildRustPackage rust projects

a graph showing similar crates.io dependencie configurations in 2312 buildRustPackage rust projects.

📊 interactive d3 graph (30s load time)

findings:

nixpkgs 1c3d5a53f03f2eb5677f6f3b34f0ef31261ba485 we find 2574 rust programs compiled via buildRustPackage.
with 2312 (out of the 2574) i could use for statistics (that is 90% of all buildRustPackages usages)
these 2312 rust projects have 360909 crates.io dependencies and on average each project has 360909/2312 = 158 dependencies
out of 360909 crates.io dependencies, only 44248 are unique crates.io dependencies, meaning there is a huge set of crates which are compiled with an identical configuration

hypothesis

cargo-libnix already is capable of reusing compiled libraries and thus we would have to build 8.1 times less dependencies! it remains to be seen if this 8.1 factor translates in 8.1 compile time and it could be more or even less.

hydra.nixos.org on average, would then only have to compile 158/8 = ~20 dependencies per rust project when picking up a new project and start working on them and instead they would use binary substitudes
in the age of AI cargo+libnix could speed up things even more as agents are far more wasteful with repository checkouts and rebuilds than humans are (a hunch of mine, needs proper backing)
rustc supports incremental builds and we could even wrap that into dynamic derivations

it would be interesting to compile a list of build times, source code checkout size and binary store path size for each of the 44248 unique crates.io crates and then use these build statistics to get a measurement on the actual combined build times and disk space impacts.

summary

using the integration of cargo+libnix could lead to improved build efficiency, faster onboarding, and a more streamlined developer experiences.

shoutout to the nixpkgs maintainers: excellent work! without your diligent efforts in maintaining this extensive collection of software, i wouldn’t have been able to gather such valuable data.