 | Nix Rust | 708 Members |
| Rust | 158 Servers |
| Nix Rust | 708 Members |
| Rust | 158 Servers |
| Sender | Message | Time |
|---|---|---|
| 25 Mar 2025 | ||
 Toma | yes, I believe | 13:58:25 |
 emily | right | 13:58:32 |
| emily | is your concern that people need to be able to write packages compatible with both 24.11 and 25.05? | 13:58:41 |
| emily | I believe they can do that by setting it explicitly to true. | 13:58:58 |
| emily | we can't avoid 25.05 having a breaking change from 24.11, because 1.85 already broke all the hashes | 13:59:03 |
| Toma | True, and they will get warned anyways | 13:59:10 |
| 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 |