 | Nix Hackers | 884 Members |
| For people hacking on the Nix package manager itself | 189 Servers |
| Nix Hackers | 884 Members |
| For people hacking on the Nix package manager itself | 189 Servers |
| Sender | Message | Time |
|---|---|---|
| 31 Mar 2025 | ||
 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 |
| jade_ | * we had to do effectively the same 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:35 |
| jade_ | btw now that we fixed nixpkgs to not break when you put an overlays.default shaped overlay that overrides pkgs.nix, you should write an equivalent document to https://wiki.lix.systems/books/lix-contributors/page/lix-beta-guide | 01:48:19 |
| jade_ | this is the foundation of lix's QA processes and is one of the main reasons, besides generally immediately prioritizing regressions on main, that lix has relatively few bugs. | 01:52:40 |
| jade_ | * this is the foundation of lix's QA processes and is one of the main reasons, besides generally immediately prioritizing regressions on main when they are found, that lix has relatively few bugs. | 01:52:54 |
 fzakaria | what's new nix ? | 02:45:45 |
| jade_ | it's like updog (i assume they actually mean the master branch) | 05:28:09 |
 roberth | I'm a fan of IFD too, but I don't see how it helps here | 08:09:11 |
| roberth | goes to show that fetchTree and its tests are in a bad state and needs to be experimental for another while, as implementers (not just us) figure out what the right behavior should even be. It sucks | 08:13:04 |
| roberth | I agree that breaking changes should be in the release notes, also for experimental features | 08:14:02 |
 leona | This seems about right. John Ericson: I understand your thoughts and constraints. I'm not an expert for the packaging for nix packaging tho. By assuring me that you will be available for fixing broken things, I'm okay with updating nix before the first freeze period (2025-04-09). I trust you with your judgement. Also, I will try nix 2.27 as soon as packaging is ready-enough in nixpkgs. | 08:36:54 |
| leona | I think it would also be good to backport 2.27 to 24.11 (inside nixVersions). That way people on 24.11 can also test compatibility. | 08:40:39 |
 Hemant Baviskar set a profile picture. | 09:30:34 | |
 p14 | I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available. One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false. Should the ca metadata be missing in this scenario? Is there a way to put it there? | 13:09:32 |
 Sandro 🐧 changed their display name from Sandro 🐧 to Sandro 🐧 [c3d2]. | 13:58:06 | |
| Sandro 🐧 changed their display name from Sandro 🐧 [c3d2] to Sandro 🐧. | 13:59:29 | |
 toonn | I don't really follow the reasoning here, https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2767289529 The build system for Nix 2.24 is already packaged, no? So why would 25.05 sticking to that version of Nix mean having to maintain two build systems? GHC very intentionally did a gradual shift and the Make based build system hasn't been supported as of 9.6.1 from 2023-03-10 latest | 15:37:04 |