| 31 Mar 2025 |
 John Ericson | (but I also walked out to eat) | 21:34:03 |
 @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 :) | 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 |
| llakala | hopefully we can eventually get to the point where IFD isn't a problem | 22:00:37 |
| llakala | as Tvix/Snix shows us, it is indeed possible | 22:01:01 |
| raitobezarius | In reply to @roberthensing:matrix.org
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 i kinda disagree with this portrayal of the current state of things, there was a naturally developed API for overriding packages which is explained in Nix pills and stuff, overrideAttrs has some standard expectations: you can override patches, etc, etc.
this all solidified quite well without many efforts thanks to automatic injection of these attributes and pushing packagers to use a set of mostly standard APIs, of course, some packagers went their own way, e.g. python3Packages and the suffering caused by that is reported constantly in the well known issue, I don't think a day passed with people saying "I'm glad that python3Packages has its own API for override and its own contract" that no one knows
having an API to inject your own override / overrideAttrs is 95 % of the time not needed, most packages have absolutely boring needs | 22:03:38 |
| raitobezarius | the interface boundary kinda exist today, it just is not super well made for package sets indeed, but there's already a bunch of this that already works and arguably the Nix implementation is even more complicated than a trivial package set and the current situation with nixForLinking does not really address the "let me choose my Nix version while importing nixpkgs once" | 22:04:56 |
| Robert Hensing (roberth) | yeah I was replying to trofi's scenario :) | 22:07:06 |
