So crane does implement per-crate builds?

[dpc]

I've kind assumed that crane builds one large derivation for all the dependencies. But when switching from github action to cachix cache in the CI, I've immediately noticed that crane seems to be able to re-use build for each dependency somehow, and they show up as a separate cacheable artifact...

... which is AWESOME. I just want to confirm that this is indeed the case, and I think the README and documentation could be more clear about it.

It also makes using cachix for caching sooo much better over a standard github action cache.

[ipetkov]

By default buildPackage will build everything in two derivations:

1. the first runs cargo check, cargo build, and cargo test with all dependencies but without the actual source of the project
2. the second builds with the crate source and the artifacts from the previous step

Technically whenever you run another command (like cargoClippy or cargoAudit etc.) they are also done in their own derivation which allows for more granular builds (or farming them out to multiple builders in parallel), though in practice they will all probably need to be rebuilt as the crate source changes.

I did try to explain this in the "Philosophy" section of the README, though it can probably be split out to be a bit clearer 😅

[dpc]

That was also my understanding, but now I'm confused.

When we run stuff in the with cachix enabled it copies something that looks per-package:

 these 703 paths will be fetched (731.00 MiB download, 2501.74 MiB unpacked):
  /nix/store/001xcnwakhcfrnlmbajf754d6x8pkhg1-configureCargoCommonVarsHook
  /nix/store/004217z94skkdd664v74aa1a43x1xq7b-cargo-package-aho-corasick-0.7.18
  /nix/store/00d196bbncisks5amrximqmia6p6w204-cargo-package-mime-0.3.16
  /nix/store/02wkw57485l3g1h32j7vi2zq51z5bxq3-fnv-1.0.7
  /nix/store/040j4n4hbadncwsmv9iqg39l5v4q4wgi-cargo-package-crossbeam-epoch-0.9.10
  /nix/store/04qbvv0dp3mzb320g4ak6xx3wkmfri05-opaque-debug-0.3.0
  /nix/store/04v18jx2brlmff38c7f3a8sclbnygljp-cargo-package-winapi-util-0.1.5
  /nix/store/069i7sasmcvwxwz3dx2g55xmnl38zjb1-openssl-1.1.1q-dev
  /nix/store/0762yl6aymzwlb3wvcfxkz6rq4gqjmrh-zstd-1.5.2-bin
  /nix/store/0aiiplfhplxydrs91n6js7hch8b237xx-cargo-package-integer-encoding-3.0.4
  /nix/store/0c5fxigqm18qhghmkqy61296s849wvyp-jobserver-0.1.24
  /nix/store/0cr4rmy0vn29846vc4a4k4cixgbfkz3z-arrayvec-0.7.2
  /nix/store/0i60zxxhb7zxn5cp0xbh0k8bmxm84cn7-termcolor-1.1.3
  /nix/store/0kx0m1dyby3q7ngww9x7k1ikdl3h1x60-cargo-package-unicode-normalization-0.1.21
  /nix/store/0l58wd4hb6qixc82pv6jx14xmlqz0nb5-validator_derive-0.13.0
  /nix/store/0ngvkk6ldir6072rr33jay44phi0p3fr-tracing-subscriber-0.3.15
  /nix/store/0rgm65ymq6hhkf4b3sy0qqadckkypndv-cargo-package-tokio-1.20.1
  /nix/store/0rny5vx84hmddfadz40wrz4wm1gxxp7y-cargo-package-tap-1.0.1
  /nix/store/0vdzclflbbmlq0y509prp7fn8jv5pl8j-cargo-package-httparse-1.7.1

full output at https://github.com/fedimint/fedimint/runs/7789690774?check_suite_focus=true

[dpc]

Very notably, even when major things change, I don't see a +10minutes build of rocksdb-sys which would otherwise be very painful, so I believe with cachix nix is able to use some of the underlying things even when workspace dependencies need a rebuild?

[ipetkov]

When we run stuff in the with cachix enabled it copies something that looks per-package:

Ah yes, these are the derivations which download and unpack the tarball from crates.io. So technically there are lots of different derivations which can be run as part of the build, but these are just downloading the sources. Crates (cannot easily) be built and cached on their own due to how cargo enables and builds different feature flags so that's why crane will build the whole dependency tree in one go and cache that!

Very notably, even when major things change, I don't see a +10minutes build of rocksdb-sys which would otherwise be very painful, so I believe with cachix nix is able to use some of the underlying things even when workspace dependencies need a rebuild?

The only inputs seen by the derivation that builds the dependencies is the entire Cargo.lock file and a small subset of the Cargo.toml file. As long as those relevant parts do not change, that derivation's cache can and will be reused! Updating the Cargo.lock file will require re-building everything again, though most projects don't update their lock file on every commit and the caching works well.

[dpc]

I see. So these files that I see being copied from cache are only the downloaded source code of each package. Thanks a lot, that explains it!