| 31 Mar 2025 |
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 |
| 1 Apr 2025 |
emily | John Ericson: btw, I wanted to say thanks for engaging, and sorry for getting frustrated. I don't want to stand in the way of reducing version drift, getting rid of autotools, making Nix more modular and maintainable. just want to make sure that the root causes of 2.18 type situations are addressed by getting properly in tune with the constraints Nixpkgs is under | 00:52:23 |
emily | (or in the way of properly-defined interfaces in Nixpkgs, either) | 00:54:28 |