| 25 Mar 2025 |
 emily | I assume nothing? but I'm not sure what you're asking | 13:56:21 |
| emily | 24.11 is on whatever Rust version it released with for its lifespan | 13:56:27 |
| emily | even if we add rustc_1_85 in the next few months, it won't be default, so there'd be no breaking change (I guess we'd have to backport the new machinery in that case) | 13:56:57 |
 Toma | let's say we make useFetchCargoVendor default now, will we backport that or no? | 13:57:52 |
| emily | no | 13:58:05 |
| emily | we don't backport breaking changes | 13:58:12 |
| emily | is useFetchCargoVendor even in 24.11? | 13:58:15 |
| 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 kubernix we
- flip
useFetchCargoVendor to true by default, add an assertion that it's not false
- rip out the old fetching machinery entirely
- document that in the release notes
| 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 |
