Stackage for Rust + Nix

[therishidesai]

Crane is great for single crate/executable projects but as projects get bigger with multiple programs or utilizing cargo workspaces builds get slow and caching is poorly utilized. Specifically if I have 4 rust packages that all use the same tokio crate, they all have their own build of tokio in their nix store path even though that dependency should be shareable. The Haskell ecosystem has Stackage which is a consistent set of Haskell package that will all build against each other. This pairs very well with Nix because Stackage solves the diamond dependency problem and then via Nix we can get library/package level cache sharing. Michael Snoyman, the creator of Stackage, has talked about why Rust doesn't need Stackage but in the nix ecosystem I think we could gain a lot from a Stackage for Rust.

Maybe building a Stackage for rust is too big of a hammer and there may be better ways of resolving the dependencies that are shared.

Im starting this discussion here since this is the best community of Rust + Nix users.

[therishidesai]

https://nix-community.github.io/crate2nix/

This may also solve what I'm looking for.

[dpc]

Benefits of derivation per-crate are overstated, benefits of bundling it all together and compressing together understated.

Specifically if I have 4 rust packages that all use the same tokio crate, they all have their own build of tokio in their nix store path even though that dependency should be shareable.

In practice if you have 4 rust packages each will want a different combination of: exact tokio version, exact tokio features, exact toolchain version and you won't get any sharing anyway.

[therishidesai]

On a NixOS machine and also in a deployed environment people already strictly enforce toolchain versions especially when these different rust programs need to talk to each other via some sort of IPC mechanism. Also on a NixOS machine we enforce a C toolchain via stdenv so I'm not sure this is that different.

[dpc]

For a NixOS building it doesn't matter this or that way much anyway. Rust packages in NixOS are not being rebuilt that often. And the differences in crate versions and featuresets remain. For these use-cases what nixpkgs are doing already seems simple and sufficient.

Projects like crane (but also crane2nix) shine in CI pipelines and flakes, where being able to compress ./target whole and throw it into cachix saves a lot of time, developers want to pin to specific toolchain versions, and build long multi-step pipelines (e.g. deps, workspace, lints, then tests), etc. and extra complexity pays for itself.

[ipetkov]

Specifically if I have 4 rust packages that all use the same tokio crate, they all have their own build of tokio in their nix store path even though that dependency should be shareable.

I will note that there are ways to optimize this. For example, it's possible to use tools like cargo-hakari to make sure that packages in the same workspace enable the same set of features of their dependencies to improve caching. Even if you choose to expose each package as a separate individual derivation, you can still build one big buildDepsOnly derivation which caches the dependencies of the entire workspace as a single copy in the Nix store