| 31 Mar 2025 |
 John Ericson | getting rid of the boost env vars (actually that was never needed) | 20:17:49 |
| John Ericson | cutting out the mkMesonPackage library stuff we don't nee | 20:18:00 |
| John Ericson | a bunch of stuff | 20:18:06 |
| John Ericson | It should be < 50% today's complexity | 20:18:18 |
| John Ericson | if you all stlll hate it, then yes we can talk about other things | 20:18:38 |
| John Ericson | but I don't think you all will | 20:18:46 |
 ElvishJerricco | well, the amount of code in #393509 is literally an eighth of what's in the to-be-rebranded nix/vendor directory | 20:21:14 |
| John Ericson | well, let's pick a ratio and hold me to it :) | 20:21:45 |
| 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 |
