| 31 Mar 2025 |
 John Ericson | (for 25.11, I would love to move it to aliases, even) | 20:37:42 |
 emily | In reply to @elvishjerricco:matrix.org
I don't have any issue with the nix version being bumped for 25.05, though leona expressed some concern about it. My issue is with the packaging expressions making it to the default nix in 25.05 even aside from packaging concerns we really do try to avoid major bumps of critical components close to release | 20:38:16 |
| emily | and Nix updates have often been comparably or more painful compared to e.g. major compiler bumps | 20:38:46 |
| emily | i will comment again later once I am no longer on phone keyboard | 20:39:03 |
 ElvishJerricco | I think the fact that Nix is a core component of the OS is a good reason that it should be bumped. We want the default version to be one that's more actively maintained, which a newer version like 2.27 or 2.28 would be. | 20:40:42 |
| emily | it's not going to be the latest for long. the Nix team policy is supporting the latest version and the one in stable Nixpkgs | 20:43:19 |
| John Ericson | emily: I think we've done fairly little feature-behavior churn since 2.24 | 20:43:23 |
| emily | which is their decision of course but it shouldn't impact Nixpkgs release cycle decisions | 20:43:37 |
| John Ericson | like, because we've been busy with this stuff, the actual behavior Nix is relatively unchunged | 20:43:47 |
| John Ericson | so I would expect a good bit less behavior difference than e.g. that between 2.18 -> 2.24 | 20:44:17 |
| John Ericson | roberth's been dogfooding new Nix, and I plan to in a moment too | 20:44:53 |
 raitobezarius | didn't output path calculation change between 2.24 and 2.28 again? | 20:45:25 |
| emily | the only way we're going to avoid the 2.18 logjam repeating over and over is if the Nix team actually puts in the effort to communicate proactively with Nixpkgs processes and take the concerns seriously rather than throwing things over the wall last minute. as so often, it's about communication. Tom's comment claimed that 2.24 would remain the default only a few hours ago before being edited | 20:45:30 |
| emily | if this had been talked about earlier the concerns could have been raised and timing could have been discussed. when I tried to use the new packaging only weeks ago it wasn't in a state to even be nixVersions.latest | 20:46:17 |
| John Ericson | Nix in Nixpkgs would have already been bumped except for the packaging churn, so there is a bit of a tangled causality here | 20:46:19 |
 roberth | not that I know of. Where would that be? | 20:46:59 |
| emily | that's your prioritization decision though... | 20:47:04 |
| emily | this is why upstream=downstream is fraught at the best of times. the incentives are just not the same | 20:47:26 |
| John Ericson | pre planet Nix I was really busy doing other stuff in Nix (and also win work, unrelated to Nix!). Now after words I stick my head up for air and see --- oh shit, new Nixpkgs is almost here, and we're really behind | 20:47:46 |
| John Ericson | I've put all the CA and dyn drv and other personal priorities on hold to get this stuff sorted | 20:48:02 |
| raitobezarius | In reply to @roberthensing:matrix.org
not that I know of. Where would that be? latest I have in mind is that output path calculation change with fetchTree and file:// between 2.19 and 2.24, I'd need to look again in my notes | 20:48:23 |
| John Ericson | get the headers, the package config, the nixpkgs legibility, and other things that need to get bumped sorted | 20:48:25 |
| raitobezarius | but I'd appreciate if this could be tested before Lix has to discover it :P | 20:48:40 |
| John Ericson | it's not the ideal timing for sure! No disagreement from me there! | 20:48:59 |
| John Ericson | raitobezarius: I recall some Lix patch that made it respect the fetching equivalent of outputHashMode | 20:49:21 |
| John Ericson | that sounds like something we should have | 20:49:26 |
| John Ericson | it didn't look like a regression | 20:49:37 |
| John Ericson | but respecting the thing does look more correct than not | 20:49:50 |
| raitobezarius | well, this was a bug that was fixed but caused output path calculation changes which goes against the contract of reproducibility | 20:50:10 |
| raitobezarius | this meant that who had in their cache had to cache bust everything | 20:50:21 |
