| 31 Mar 2025 |
 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 |
 Robert Hensing (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 | 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 |
| Robert Hensing (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 |
| Robert Hensing (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 |
| Robert Hensing (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 |
| Robert Hensing (roberth) | We might have to do something like that if overriding is really that important | 22:14:37 |
| trofi | Ah, nice. I'll give it a try. | 22:14:38 |
| Robert Hensing (roberth) | Maybe nix.overrideAttrs could throw a useful error referring to a monolithic nixVersions.nix_mono package to ease the transition | 22:17:07 |
| Robert Hensing (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 |
| ElvishJerricco | It would be handy if I could like... only patch systemd-boot and not have to rebuild everything else. Would save a minute or two per iteration while bug smashing :P Ultimately not worth very much | 22:34:56 |
 John Ericson | yes that would be fantastic! | 22:35:52 |
| John Ericson | Meson subprojects are such a killer feature | 22:35:59 |
| John Ericson | I really want to convince other projects to use them more | 22:36:07 |
| John Ericson | in general "let downstream manage the depednencies" | 22:36:17 |
| John Ericson | don't just through everything into one package because conways law | 22:36:26 |
| John Ericson | separation of concerns, fine-grained packages, downstream does bootstrap --- por que no los tres! | 22:36:49 |
