| 25 Mar 2025 |
 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
- 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: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 |
| Toma | btw we're still using replace-workspace-values.py in fetchCargoVendor | 14:14:42 |
| emily | yeah I saw :) | 14:14:48 |
| emily | anyway, ok, this is a distraction. if we want to do that we can do it another release anyway | 14:15:16 |
| emily | but I think we should do this now before we forget :P | 14:15:26 |
| emily | I'm reproducing system-syzygy before merging | 14:15:38 |
| emily | fwiw, the thing about supporting old lock files isn't so much about existing packages but the fact that I find it hard to imagine a PR to add a new one that we'd want to accept | 14:19:04 |
| emily | so given the existence of a fallback path in the form of importCargoLock it seems bad to add any complexity to our current infrastructure for it | 14:19:31 |
| Toma | yeah, not worth rebuilding so many packages for those | 14:24:01 |
| Toma | I know i've already sent this in a few times, but:
https://github.com/NixOS/nixpkgs/pull/390171 | 14:25:49 |
| emily | not sure I understand this PR enough to approve it without reading up more on the issue | 14:27:52 |
| emily | Toma: are you up for doing this or would you like me to have a go at it? | 15:13:08 |
