| 31 Mar 2025 |
 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 |
 roberth | yeah I was replying to trofi's scenario :) | 22:07:06 |
| roberth | not the current state of things | 22:07:16 |
 @trofi:matrix.org | heh :) | 22:07:35 |
| raitobezarius | i may read too much into what trofi said | 22:07:42 |
| raitobezarius | but i thought it would describe a smaller or more-difficult-to-maintain nixpkgs ;P | 22:07:54 |
| roberth | with the new packaging we've tried to stick as much to established APIs like plain mkDerivation without added fixed-points on top | 22:10:07 |
| @trofi:matrix.org | I had to throw away a bunch of .nix code that added env.NIX_CFLAGS_COMPILE =" -D_GLIBCXX_DEBUG"; to nix package because I have no idea how to do it for nix-2.26. For other package sets in nixpkgs my default action of to stick a patch into local nixpkgs checkout because I have no idea how they work from a set to a set. | 22:10:17 |
| roberth | I think the packaging layers we've developed for mkDerivation could be useful outside Nix for other meson-based projects | 22:10:46 |
| raitobezarius | as I kind of have joint authority over the Nixpkgs packaging of Lix, I read it but I'm not super convinced personally | 22:11:27 |
| raitobezarius | I feel like it violates too the principle of least astonishment for packagers and consumers | 22:11:37 |
| raitobezarius | Like it's interesting from a technological PoV | 22:11:42 |
| raitobezarius | But I would not use this for Lix because this is far too out of the Overton window on how do you do packaging in Nixpkgs | 22:12:00 |
| roberth | .overrideAllMesonPackages is like .overrideAttrs but for all packages at once | 22:12:10 |
| raitobezarius | If it were up to me, I'd have duplicated the experimental packaging and the normal packaging | 22:12:14 |
| raitobezarius | And keep both for a while while documenting how to do things in the normal way in the newest way | 22:12:27 |
| raitobezarius | In reply to @roberthensing:matrix.org
.overrideAllMesonPackages is like .overrideAttrs but for all packages at once I kinda don't understand why this is not just like an .override at the scope level | 22:12:57 |
| raitobezarius | and why does it have to be a overrideAllMesonPackages | 22:13:08 |
| roberth | .override is for a single callPackage call. This is a package set | 22:13:29 |
| raitobezarius | If the package set gets callPackage while taking the scope as args, you can override the packages inside of the set with a single .override call | 22:14:25 |
| raitobezarius | or am I missing something? | 22:14:31 |
| roberth | We might have to do something like that if overriding is really that important | 22:14:37 |
| @trofi:matrix.org | Ah, nice. I'll give it a try. | 22:14:38 |
| roberth | Maybe nix.overrideAttrs could throw a useful error referring to a monolithic nixVersions.nix_mono package to ease the transition | 22:17:07 |
| roberth | as well as docs that refer to it | 22:17:44 |
 ElvishJerricco | I've thought about using it for systemd. Like if udev could go back to being a separate package, that would tremendously ease the dependency graph of nixpkgs. The tradeoffs haven't seemed worth it yet though. | 22:30:40 |
| raitobezarius | nikstur would be really angry for sure hahaha | 22:31:54 |
