| 31 Mar 2025 |
 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:matrix.org | 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 |
| emily | FWIW, while I think it's best to leave the ultimate judgement calls up to the release manager here, I'll say that if you wanted to maximize the chances of getting autotools out the door and start the transition to a componentized Nix, this seems like the smoothest plan to me: bump to the latest version but ditch the everything package, since it's a transition mechanism that fails to fully support the transition, and dropping it will save some complexity. instead just offer both a "classic" monolithic build and the new components as a tech preview. implement shims for the componentized overrides in the monolithic build, and make using the deprecated override style on it warn and point out the new ways to accomplish things in the componentized build | 00:55:18 |
| emily | it's certainly some unfortunate temporary duplication, but it makes Meson happen and paves the way to seamlessly swap things over by the next release | 00:56:00 |
| emily | anyway, I think I said most of what I had to say in the comment I was going to write, so I'll hold off until further developments :) | 00:56:20 |
 jade_ | we had to pick that change in lix 2.93 because it turns out it was ill-designed from the beginning and the previous behaviour was severely broken in a very hard to fix way that caused eval to be nondeterministic (which seemed like a bigger sin).
the issue i have is not that the output path changed; i don't particularly care about that; but it needs to be in the Breaking Changes section like it is in lix. | 01:44:28 |
| jade_ | * we had to pick that change in lix 2.93 because it turns out it was ill-designed from the beginning and the previous behaviour was severely broken in a very hard to fix way that caused eval to be nondeterministic (which seemed like a bigger sin).
the issue i have is not that the output path changed; i don't particularly care about that; but it needs to be in the Breaking Changes section and done on purpose like it is in lix. | 01:45:14 |
