How to integrate vendoring of dependencies & cache with direnv / VS Code / Devcontainers / Codespaces?

[edulix]

First, thanks @ipetkov for making development easier for Rust developers that use Nix.

I'm trying to figure out how to best integrate crane in our tooling. The project I'm working on is https://github.com/sequentech/bulletin-board (open source and has Nix Flake and other tools integrated). Crane has clear the advantages for CI tasks and Nix.

The questions I have revolve how to reuse/integrate the cache of the build that is generated from Nix with Crane into the rest of the development tooling:

1. VS Code has integration with Rust. For example, it builds the code and highlights compiler errors. It also allows to run and debug using launch.json and launch tasks using tasks.json. How can the build cache from nix/crane be reused so that vscode doesn't do this from scratch?
2. Within VS Code command line (which uses direnv), I want to also be able to run cargo build etc and not start the build from scratch.
3. Is there any example of how to take advantage of cachix in previous cases and also during Codespaces Prebuilds? Right now, our prebuilds take around 30 minutes because of compiling multiple times with no caching.
4. Is it advisable to have two different set of derivations, one with rust debug target (that maybe is loaded in the devShell with direnv), and the other for final version with release target?

I suspect I should approach this using some of the API calls like lib.vendorCargoDeps, but I don't know exactly how.

[dpc]

There's a big difference between the local developer workflows (1 and 2) which typically is just a nix develop / direnv based and the CI build (where you'd use most of crane features).

nix develop shell so it provides tools necessary for building (rust toolchain, cargo, etc.) and have developer run normal cargo build.

I don't see a practical way to combine them, though caching will re-use build inputs between dev shell and CI.

Is there any example of how to take advantage of cachix

You should use cachix. It's a huge improvement. It comes down to creating account, putting secret in your github settings and using the appropriate actions to use it.

https://github.com/fedimint/fedimint/blob/32d9423f47ceeee170a81f688f3c67f50b47c555/.github/workflows/ci-nix.yml#L24

You can put your cachix in your flake.nix https://github.com/fedimint/fedimint/blob/32d9423f47ceeee170a81f688f3c67f50b47c555/flake.nix#L947 so the developers will be asked do they want to trust it and use it locally. It makes a difference only for some unconventional build inputs (that wouldn't be already in normal nixpkgs cache) or if these developers actually run nix build ... locally.

Is it advisable to have two different set of derivations, one with rust debug target (that maybe is loaded in the devShell with direnv), and the other for final version with release target?

I've built a system that derives debug flake outputs from normal flake outputs if you are interested. https://github.com/fedimint/fedimint/blob/32d9423f47ceeee170a81f688f3c67f50b47c555/flake.nix#L668

In CI we build and test debug builds, but for containers and anything release-like we use release ones.

If you go this route and e.g. run tests in debug builds, make sure to have cargo build most computational heavy dependencies with optimizations https://github.com/fedimint/fedimint/blob/32d9423f47ceeee170a81f688f3c67f50b47c555/Cargo.toml#L50

[ipetkov]

Hi @edulix!

1. [...] How can the build cache from nix/crane be reused so that vscode doesn't do this from scratch?

In theory this may be possible to achieve but I have not yet seen it done in practice: one could imagine defining a Nix derivation which invokes cargo check or cargo clippy and saves their json output, then configuring rust-analyzer to call Nix and then inspect the result of the derivation. I don't know all of rust-analyzer's internals and how it plays with analyzing proc-macros, for example, and how nicely that would play with trying to reuse the artifacts built directly by Nix (though if anyone has a working example of this I would be very interested to see!).

For my projects I usually stick with rust-analyzer building things locally and the CI building things via Nix, though unfortunately this won't take advantage of the cached artifacts.

2. Within VS Code command line (which uses direnv), I want to also be able to run `cargo build` etc and not start the build from scratch.

I briefly tried experimenting with this a while back by copying the artifacts out of the Nix store locally and then trying to run cargo build on top of that. What I found out was that cargo couldn't successfully use the artifacts (I can't remember if it would error out or just and up rebuilding everything from scratch). My sneaking suspicion was that changing the path of where the artifacts were initially compiled would confuse cargo.

If this issue ever gets resolved you could at least bootstrap local builds that way, but I haven't had any success myself.

3. Is there any example of how to take advantage of cachix in previous cases and also during Codespaces Prebuilds?

I haven't used codespaces myself yet, but if you are somehow invoking Nix through it they should be able to take advantage of cachix just like you would anywhere else (either in CI or locally). I'd checkout the cachix docs (or the example @dpc mentioned) for some inspiration!

4. Is it advisable to have two different set of derivations, one with rust debug target (that maybe is loaded in the devShell with direnv), and the other for final version with release target?

Crane allows this to be fully configurable so it's entirely up to you! The defaults will build in release mode since that's probably what downstream consumers would want to use anyway, but if you find it useful to have a separate set of derivations which build in debug mode for CI/flake checks feel free to take that approach!

[edulix]

Thank you guys for the detailed responses. I'll keep investigating a bit what can I achieve and report back here when I have something interesting and related to the topics mentioned.