 | Nix Rust | 707 Members |
| Rust | 158 Servers |
| Nix Rust | 707 Members |
| Rust | 158 Servers |
| Sender | Message | Time |
|---|---|---|
| 25 Mar 2025 | ||
 emily | so since we're locked in to a breaking change, we should make it the safest and most ergonomic one that avoids old hashes being used from the cache and makes things work without setting a flag manually | 13:59:21 |
| emily | shipping with useFetchCargoVendor = false; as the default means either (a) dangerous reuse of cached FODs that now don't reproduce, if we keep the old mechanism or (b) if we remove the old mechanism (which I think we ought to), you have to set a flag on every Rust package just to get it to eval, which is silly | 14:00:15 |
| emily | BTW, one thing we could do is have the FOD derivation print "hey, btw, if the hash mismatches after you upgraded to 25.05 this is expected because of Rust 1.85, just update it, and if you need 24.11 back-compat then set useFetchCargoVendor = true; explicitly", right before failing | 14:00:58 |
| emily | if we're worried about users getting confused when updating | 14:01:05 |
| emily | I don't think that's strictly mandatory though, stuff breaks in Nixpkgs with less handholding than that 🫠| 14:02:05 |
| emily | I would suggest that after we drop
| 14:02:49 |
 Toma | kubernix uses importCargoLock, no need to wait for that | 14:03:39 |
| emily | fair enough | 14:03:52 |
| emily | we should probably drop it anyway though… | 14:03:55 |
| Toma | yeh | 14:03:59 |
| emily | like it looks pretty knownVulnerabilities, it pins Kubernetes components from over half a decade ago | 14:04:11 |
| emily | does importCargoLock handle the "same package from two different registries" thing btw? | 14:04:48 |
| Toma | I don't think so | 14:04:56 |
| emily | I am wondering if it makes sense to allow fetchCargoVendor to be driven by a Cargo.lock to avoid maintaining two paths for all of this altogether. but that's not release-blocking | 14:07:20 |
| Toma | after my last few migrations to fetchCargoVendor get merged, almost all other packages that still have a Cargo.lock vendored do it because of upstream not publishing it | 14:07:29 |
| Toma | not sure I understand | 14:08:08 |
| emily | we could have a mode where you supply a Cargo.lock and a hash, right? | 14:08:38 |
| emily | which would meet the "no upstream Cargo.lock" use case and ~obsolete importCargoLock | 14:08:53 |
| Toma | I guess very much like with fetchYarnDeps | 14:09:44 |
| Toma | but for historical reasons almost everyone uses ${src}/yarn.lock instead of inherit src there (it's not IFD, since it only uses that in the build process) | 14:10:37 |
| emily | https://github.com/NixOS/nixpkgs/blob/15f3d37c73c8c1090f8fef7b8508675c9260eab6/pkgs/build-support/rust/import-cargo-lock.nix
isn't a trivial maintenance burden, so if 25.05 is doing breaking changes anyway, it might be best to eliminate it | 14:11:05 |
| emily | * https://github.com/NixOS/nixpkgs/blob/15f3d37c73c8c1090f8fef7b8508675c9260eab6/pkgs/build-support/rust/import-cargo-lock.nix + https://github.com/NixOS/nixpkgs/blob/15f3d37c73c8c1090f8fef7b8508675c9260eab6/pkgs/build-support/rust/replace-workspace-values.py isn't a trivial maintenance burden, so if 25.05 is doing breaking changes anyway, it might be best to eliminate it | 14:11:09 |
| emily | ah I guess we use the latter in fetchCargoVendor too | 14:11:34 |
| emily | so it's not so bad | 14:11:35 |
| emily | but it still seems better to just consolidate | 14:11:45 |
| Toma | if still thinking of how we could replace depsExtraArgs with a better alterative | 14:12:27 |
| Toma | * if still thinking of how we could replace depsExtraArgs with a better alterative (semi related) | 14:13:03 |
| emily | it looks like we could add lockFileContents ? null and lockFile ? null to fetchCargoVendor, and simply replace ./Cargo.lock with ${if lockFile != null then "${lockFile}" else if lockFileContents != null then writeText … else "./Cargo.lock"} | 14:13:47 |
| emily | I guess the downside is for "local" flakes with Rust packages though | 14:14:20 |
| emily | so maybe it is not a good idea, even if it is better for Nixpkgs | 14:14:32 |