| 3 Dec 2025 |
dish [Fox/It/She] | i dont have a preference personally since I dont use them | 22:27:03 |
dish [Fox/It/She] | but that's the main reason to use them | 22:27:09 |
dish [Fox/It/She] | since they have binary caches so you dont have to build rustc from source(which would happen if you overrode nixpkgs' rustc version) | 22:27:29 |
neobrain | Oh, I was thinking among the other nix options (naersk, carnix, etc) that are listed on the wiki | 22:32:52 |
rosssmyth | Yes!
- Currently if cross compiling for mingw
buildRustPackage makes it a bit worse than the other builders
buildRustPackage does no caching of dependencies. This means that every time you run nix build it will rebuild every dependency. The others generally do not to varying levels of granularity.
For projects I author I generally use Crane. You can do some smart caching so that it's pretty fast in CI.
| 22:33:06 |
neobrain | For development I'm just going to nix develop either way | 22:33:08 |
neobrain | * Oh, I was thinking among the other nix options (naersk, crane, etc) that are listed on the wiki | 22:33:42 |
neobrain | Interesting point about caching of dependencies. I would've assumed the mapping of Cargo.lock would create a separate nix store entry for each dependency (and hence trivially cache things), but I'm probably underestimating the problem space :) | 22:35:27 |
dish [Fox/It/She] | sorry, thats what I meant. I see the main value prob of the {naersk,crane,fenix,etc} solutions as being that they allow using betas/nightlys if wanted | 22:35:42 |
dish [Fox/It/She] | I'm not a rust dev but that is one of the main things I've noticed | 22:35:52 |
neobrain | Ah, gotcha | 22:36:04 |
dish [Fox/It/She] | maybe I'm wrong in that way but from my usage in the past thats been my reason to use them | 22:36:10 |
dish [Fox/It/She] | * maybe I'm wrong in that way but from my usage in the past thats been my reason to use them over buildRustPackage | 22:36:13 |
dish [Fox/It/She] | since I just use cargo during active dev | 22:36:42 |