| 31 Mar 2025 |
 John Ericson | in here, or in https://jitsi.lassul.us/nix-maintainers | 20:07:52 |
 ElvishJerricco | 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. | 20:13:56 |
|  Hemant Baviskar removed their profile picture. | 20:14:04 |
| John Ericson | ElvishJerricco: we have to separate "package set" vs "all the other crap involved in trying to make it copy-paste job" | 20:14:46 |
| John Ericson | I know the current thing is not tenable | 20:14:57 |
| John Ericson | but it does not logically follow that that means we have to go all the way back to one giant package with a bazillion different flags | 20:15:14 |
| ElvishJerricco | I think that maintaining status quo with a mono-package is better than making the problematic thing the default. | 20:16:04 |
| John Ericson | I personally found the "big giant package" and "big giant configure script" and "big giant makefile" very daunting to work with, having wrestled with a lot of that in-tree | 20:16:43 |
| ElvishJerricco | it doesn't have to be a choice between those two things; e.g. we could redo it with a simpler and more commonly understood code base. But that would take a lot more time and effort than just returning to status quo | 20:16:45 |
| John Ericson | yes, this is what I am trying to do | 20:17:01 |
| John Ericson | the PR from robert it just the first wee bit of that | 20:17:10 |
| John Ericson | getting rid of /vendor/ the .version | 20:17:19 |
| John Ericson | and deduplicating the deps with pre Meson and post meson | 20:17:28 |
| John Ericson | then comes getting rid of the file sets | 20:17:39 |
| 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 |
