 | Nix Hackers | 899 Members |
| For people hacking on the Nix package manager itself | 188 Servers |
| Nix Hackers | 899 Members |
| For people hacking on the Nix package manager itself | 188 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Apr 2025 | ||
 Las | Say I want to output a CA derivation, something like echo hello > /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9,to be used in a downstream dynamic derivation. I don't think this is possible if the placeholder path is also /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9 for the derivation producing the derivation, which seems to be plausible since it seems to be determined by the output name only from testing? | 12:30:10 |
| Las | I really think there needs to be a way to avoid using placeholder paths entirely. They're a code smell. | 12:30:36 |
| Las | The output path should always be at /outputs/<output name> IMO, even if placeholder paths are needed for self-references. | 12:31:28 |
| Las | or is the placeholder path not supposed to depend only on the output name, and I'm testing it wrong somehow? | 12:33:51 |
 @ser:sergevictor.eu left the room. | 13:22:49 | |
 leona | It's uncool that https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2766317573 was just merged as additionally you said that you want to make 2.27 the new default and also that 2.28 has API breakages | 21:15:26 |
| leona | * It's uncool that https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2766317573 was just merged as additionally you said that you want to make 2.27 the new default for NixOS 25.05 and also that 2.28 has API breakages | 21:15:41 |
| leona | * It's not cool that https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2766317573 was just merged as additionally you said that you want to make 2.27 the new default for NixOS 25.05 and also that 2.28 has API breakages | 21:16:57 |
| leona | that's one of the trust issues things people have. tbh I don't really know what to do when these things change without any communication | 21:18:36 |
| leona | for me it's quite unclear how much breakage 2.28 is, but there was already some fallout in #infra:nixos.org so i'm not that confident. | 21:20:49 |
 emily | tbf the next comment did say 2.28 https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2767120782 | 21:20:51 |
| leona | I don't really see another comment actually mentioning "2.28 is the default" even though 2.28 was mentioned | 21:21:37 |
| emily | (I believe 2.28 is to address a bunch of awkward things about the way the Nix headers are organized that I reported when trying to use 2.26, but I do agree that the rush is scary) | 21:21:42 |
 @bradlugo:matrix.org left the room. | 23:04:22 | |
| 9 Apr 2025 | ||
 WeetHet | Wait I though it was decided to keep 2.24 as stable for 25.05 | 10:10:40 |
| WeetHet | * Wait I thought it was decided to keep 2.24 as stable for 25.05 | 10:10:45 |
| WeetHet | Why was this merged? https://github.com/NixOS/nixpkgs/pull/396442 | 10:11:10 |
| WeetHet | IMHO it's a very bad idea to bump stable nix version this close to release | 10:14:05 |
 roberth | We've discussed this with the release managers and they agreed, conditioned on having a monolithic packaging instead of the split one, which will be for 2.29+ | 10:46:54 |
| roberth | The release is still about 2 months out, and we'll be paying close attention to any issues that may arise | 10:47:53 |
| emily | (it seems like the release manager did not have the same understanding) | 10:48:37 |
| roberth | 2.28 is a continuation of 2.27. The C++ headers are not considered a stable API, but despite that, we went out of our way to signal this change with a more significant version bump. Maybe we shouldn't have called it 2.28 because of that, but we made these changes to solve real problems downstream projects have when linking against Nix | 10:51:53 |
| roberth | The only breakage is moving the location of the header files, so there's no behavioral change, and no risk to stability associated with that | 10:53:07 |
| emily | my personal understanding was also that 2.28 was the intention after the last long discussion in here, I'm just pointing out that the release manager expressed in here yesterday that it was unexpected/not communicated clearly in her view. I'm not the one to talk to here :) (the comments on GitHub were ambiguous and edited a bunch and most people probably did not read the entire discussion in this room, which I don't think the result of got summarized in any Nixpkgs space) | 10:56:00 |
| emily | (FWIW, I did strongly advocate for the header change while trying to use the C++ API with 2.26, so I have no opposition to it in general as a change on its own merits) | 10:56:35 |
| leona | I can only say that I personally don't have much insight into the development of Nix and can't see how much breakage potential a change (like this) can have. And the communication around it is complicated. Personally, I just wish there was better communication. | 11:03:59 |
| leona | I have just seen the breakages in infra and they have worried me... | 11:04:42 |
 Sandro 🐧 | In reply to @leona:leona.isSome packages where pinned and the nixpkgs-review showed that only nixStatic failed | 11:33:43 |
| Sandro 🐧 | The only thing that I noticed myself since updating from 2.24 to 2.28 was that the override interface is different | 11:34:12 |
| roberth | The override interface should be very similar now that we've made it a single derivation again, unless you were doing something make related in 2.24 | 11:38:54 |