| 31 Mar 2025 |
 John Ericson | the latter can just be fixed, and then it's good, the former is what needs time to incubate | 21:14:02 |
 emily | In reply to @Ericson2314:matrix.org
I depsartely need to eat in a moment, but also, what exactly do you (and anyone else) imagine the split package is going to break? overrides are the big one, esp for patches. and yes, the output shimming seems brittle to me, e.g. I am not sure it works with ^ or the like? the other thing is that the support code is complicated beyond any other non-compiler package set I've seen, but maybe devendoring will help that | 21:14:13 |
| emily | is it really so unreasonable to want to see one uneventful early-cycle Nix bump before we start doing them in the lead up to release coupled with breaking package rewrites? | 21:15:20 |
| emily | even 2.24 took a couple tries to stick | 21:15:30 |
| emily | and I advocated for that bump | 21:15:37 |
| emily | because I don't think the drift is good for the projects | 21:15:49 |
| emily | but the only way to solve the root cause is proactive communication and prioritization of Nixpkgs' needs and concerns for a critical component | 21:16:19 |
| John Ericson | Ultimately I will prioritize a good healthy working relationship over not delaying the split package 6 months more | 21:17:05 |
| John Ericson | but please ask yourself | 21:17:08 |
| John Ericson | the list of things above | 21:17:12 |
| John Ericson | it looks entirely like static known issues to me | 21:17:23 |
| John Ericson | I am a bit scared for 2.28 right now, yes, because that is where unknown-unknowns come from | 21:17:39 |
| John Ericson | but you already proposed we do just that (and monopackage) | 21:17:53 |
| emily | nothing blocks shipping a patching mechanism that works with both packagings in 25.06 and backporting to 24.11, right? | 21:18:00 |
| John Ericson | the marginial cost of the split package feels very low to me | 21:18:09 |
| emily | in which case we would be free to break the old way in 25.11 | 21:18:14 |
| John Ericson | because we can simply test all the things you mentioned right away | 21:18:20 |
| John Ericson | there aren't really latant issues | 21:18:24 |
| John Ericson | you mean a patching mechanism that works with split and unsplit packages? | 21:19:26 |
| John Ericson | I am not sure, probably not | 21:19:31 |
| emily | how people consume our packages is a tragic unknown. though of course we always have to draw a line somewhere but look at how breaking changes to lib are handled for how our caution should increase as the criticality does | 21:19:36 |
| emily | and again if we were keeping packaging constant but bumping version or vice versa (not possible in this case, I know), there would still be concerns but of lower magnitude | 21:20:18 |
| John Ericson | I'm thinking about it | 21:28:38 |
| John Ericson | (but I also walked out to eat) | 21:34:03 |
 trofi | I wonder what it would look like if every single nixpkgs package had their own unique helper to apply patches and change depends :) | 21:35:47 |
 Robert Hensing (roberth) | it's a package set | 21:49:10 |
| Robert Hensing (roberth) | actually I think it would be great, because we'd settle on a standard interface for doing just those things and nothing else, and we'll finally have an interface boundary | 21:49:57 |
| Robert Hensing (roberth) | overriding arbitrary internals would be frowned upon, because that is not a testable or maintainable interface. Instead, users would contribute functions, tests, and documentation to support their use cases instead of trying to work around the unpredictable internal changes in packages. It'd be glorious | 21:53:02 |
 raitobezarius | In reply to @elvishjerricco:matrix.org
raitobezarius: I would like to know an example I could use to verify whether or not Nix actually has the problem you describe. nix-eval-jobs with nix 2.X and 2.Y the entirety of nixpkgs and then compare the outPath? | 21:59:36 |
 llakala | In reply to @trofi:matrix.org
I wonder what it would look like if every single nixpkgs package had their own unique helper to apply patches and change depends :) applyPatches does this in some sense, but with IFD... | 22:00:14 |
