| 25 Mar 2025 |
 Toma | I don't really agree: it's very simple to support because importCargoLock is written in nix and can use laziness | 12:54:33 |
 K900 | I'm not thinking about it in terms of difficulty to support tbh | 12:55:04 |
| K900 | I'm thinking about it in terms of policy | 12:55:11 |
| K900 | Any software that still has a pre-v3 lockfile hasn't been touched since what, 2020? | 12:55:33 |
| K900 | We probably don't want to be shipping that | 12:55:44 |
| K900 | Even if we technically can + | 12:55:51 |
| K900 | * Even if we
technically can | 12:56:01 |
 emily | Alyssa removed like 50 packages for having old lock file versions | 13:16:42 |
| emily | so it seems a bit late to start caring about :P | 13:16:47 |
| emily | we can just bump to HEAD | 13:17:56 |
| K900 | Yeah that's what I'm saying | 13:18:08 |
| emily | I really do not think we want to ship a tool using pinned Kubernetes dependencies from 2019. https://github.com/saschagrunert/kubernix#what-is-inside | 13:18:36 |
| emily | like even if this does still function with current Nixpkgs which I am somewhat sceptical about, it's plain dangerous | 13:18:55 |
| emily | https://github.com/saschagrunert/kubernix/issues/1204 declared unmaintained upstream | 13:19:19 |
| emily | release version is apparently broken: https://github.com/saschagrunert/kubernix/issues/720 | 13:20:01 |
| Toma | https://github.com/NixOS/nixpkgs/pull/393078
https://github.com/NixOS/nixpkgs/pull/393071 | 13:39:59 |
| emily | https://mdsteele.games/syzygy/ wow, Rust game from 2016, very early! | 13:43:13 |
| emily | https://github.com/yxdunc/lipl/commit/f57e702e6d4789cb0c16521d45a8ae2c4787213d uh, hm | 13:45:33 |
| emily | ok, apparently this quotes in the "sane" way | 13:46:15 |
| emily | did we settle on a plan for useFetchCargoVendor? IMO the best route would be to make it default to true, to give an eval error on false, and to detect a fetchCargoTarball FOD in the build and reject it with a migration explanation | 13:47:31 |
| emily | since all the FODs are broken by Rust 1.85, no existing user from 24.11 is correct/safe anyway | 13:48:00 |
| emily | so we should ensure that people with cached versions of them in their store aren't "tricked" into thinking their package hasn't broken | 13:48:14 |
| emily | also, it would be really annoying to ship with a state where you have to manually set it true for every Rust package | 13:48:33 |
| Toma | yes, for sure, remove it after the branchoff
but what about 25.05, I guess we will still need to have that? | 13:49:42 |
| emily | no I meant before the branch-off | 13:50:13 |
| emily | 25.05 is what is going to break everyone | 13:50:20 |
| Toma | hmm I see | 13:50:28 |
| emily | people will have existing FOD hashes, they'll build their package again, and it will "work" because it's in the cache | 13:50:29 |
| emily | but it will not reproduce | 13:50:32 |
| emily | having the broken thing be the default is silly, so we should default useFetchCargoVendor to true. but then we do need code to detect the old FOD format so we can reject it | 13:50:49 |
