use granular caching by default = create one derivation per dependency

[milahu]

buildRustPackage should build one derivation per dependency

see also

• https://nixos.wiki/wiki/Rust#Packaging_Rust_projects_with_nix
  • crate2nix - Derivations: Many
    • in nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/rust/crate2nix/default.nix
  • cargo2nix - Derivations: Many
    • in NUR: https://github.com/milahu/nur-packages/blob/master/pkgs/development/tools/rust/cargo2nix/cargo2nix.nix
  • Derivations: How many derivations does this solution use to compile Rust code?
    • “1” means the project and all its dependencies are compiled in one derivation.
    • “2” means all dependencies are moved into a separate derivation, so the project can be updated independently, but any change to the set of dependencies rebuilds everything.
    • “Many” means each dependency is built in its own derivation, so changes to dependencies only do the minimal amount of rebuilding necessary (and, ideally, different projects can share dependencies, although I haven’t checked if this works in practice).
• https://discourse.nixos.org/t/incremental-builds/9988
  • https://github.com/edolstra/nix-make - granular caching for C projects
  • https://github.com/nmattia/snack - Nix-based incremental build tool for Haskell projects
• https://discourse.nixos.org/t/caching-local-compilation-results-for-all-compiled-packages/3516/5
  • https://github.com/edolstra/nix-make - granular caching for C projects
• https://discourse.nixos.org/t/distributed-nix-build-split-large-package-into-many-derivations/15979
  • https://news.ycombinator.com/item?id=9256844 - bazel
• https://nixos.wiki/wiki/CCache

related: cache by build phase https://discourse.nixos.org/t/splitbuildinstall-split-buildphase-and-installphase-for-large-packages/15874

[milahu]

incremental builds

a fundamental problem of nix are the long build times

when a complex build fails, you have to rebuild from scratch, and you cannot share compilation results between builds

if you have lots of money (and a cheap energy source), you "just buy a faster computer" and/or "just buy more computers"... but for low budget (and in a future of high energy costs), that wont work

incremental builds are more aggressive than granular caching, because granular caching can give a cache miss, when some *unused* input was changed (when using outPath as cache key). incremental builds would consider only *used* inputs to generate the cache key