| 31 Mar 2025 |
 John Ericson | there is some trade-off between more duplication simply because there are more packages, and more library function stuff that needs to be understood | 20:22:17 |
| John Ericson | I am happy with any point along that trade-off curve you all pick | 20:22:59 |
 Mic92 | In reply to @elvishjerricco:matrix.org
John Ericson: You've got at least 4 nixpkgs maintainers expressing dissatisfaction with the new packaging. It should be clear that something is wrong here. When Mic92 is saying "I could not longer do any work on the code", I think that is demonstrative of the harm I described in my comment. The bare minimum conclusion IMO is that the code is overly complex, and IMO the solution is to delete it and try again. Not knowing how to update is at least now with the latest pull request from Robert today | 20:23:24 |
| Mic92 | * Not knowing how to update is at least now resolved with the latest pull request from Robert today | 20:23:38 |
| John Ericson | also for the record, I've spend like 15 hours on header stuff that emily requested (and I agreed with) | 20:24:38 |
| John Ericson | I am happy that should be wrapping up today | 20:24:45 |
| John Ericson | nix/util/.....h here we come, not force include config bullshit, and separation of implementation-detail-only vs external-API/-affecting configuration variables woo! | 20:25:17 |
| John Ericson | * nix/util/<name>.hh here we come, not force include config bullshit, and separation of implementation-detail-only vs external-API/-affecting configuration variables woo! | 20:25:34 |
| John Ericson | * nix/util/<name>.hh here we come, no force-include config bullshit, and separation of implementation-detail-only vs external-API/-affecting configuration variables woo! | 20:25:43 |
 ElvishJerricco | To me, I think the ideal solution here is to push all of this back until after 25.05 branchoff. That way 25.05 gets the new Nix version and doesn't require experimental packaging. After branchoff, we can go back to the componentized build and we'll have the length of an entire release cycle to iterate on it and make it ready for 25.11 | 20:28:26 |
| John Ericson | ElvishJerricco: So you are saying do 2.28, but with the monopackage? | 20:31:04 |
| ElvishJerricco | yea | 20:31:12 |
| ElvishJerricco | 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 | 20:32:21 |
| John Ericson | ElvishJerricco: Yeah, not gonna lie 2.28 in Nixpkgs alone is way better than 2.24 | 20:35:10 |
| John Ericson | I would be fine falling back to that at the first sign of trouble | 20:35:44 |
| John Ericson | but I'm pretty confident the issues are not human not machine? Like while the code needs tto be made legible, but it is working now. | 20:36:17 |
| John Ericson | the touchiest part is the package that combines the other packages | 20:36:59 |
| John Ericson | but as I bump things, I hope to make them not use that | 20:37:06 |
| John Ericson | (e.g. if you need a library, just depend on that library) | 20:37:18 |
| John Ericson | so the exposure of the "everything" package should go down down down | 20:37:31 |
| 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 |
