| 19 Feb 2025 |
 emily | if you mean using -march=native to get an impure build, I'd suggest just not doing that. it's cheap to specify the relevant platform explicitly and fixes the determinism issue | 14:12:57 |
| emily | FYI, the 2.26 update breaks buildInputs = [ nixVersions.nix_2_26 ]; | 23:03:20 |
| emily | it has .dev and .libs (should be .lib?) attributes in passthru, but those are not proper outputs | 23:03:41 |
| emily | uh, and .dev is just … empty | 23:04:21 |
| emily | ok I guess you have to use .dev.dev. anyway this is very weird and breaking. | 23:05:16 |
 ElvishJerricco | emily: yes, 2.26 is now componentized and the nix_2_26 build is basically just a symlink farm of all the components | 23:27:18 |
| ElvishJerricco | you have to depend on the specific libs you need via the libs passthru I think | 23:27:53 |
 Robert Hensing (roberth) | working on it | 23:28:09 |
| ElvishJerricco | Robert Hensing (roberth): Does nixpkgs actually benefit from this style of packaging for Nix? I can see the utility while iterating on Nix, but I'm not sure componentized builds are actually benefiting any users or applications in nixpkgs, and it breaks a lot of norms | 23:29:22 |
| ElvishJerricco | I'm open to it; but I'm interested in the use case | 23:30:17 |
| Robert Hensing (roberth) | I'll refer to here https://github.com/NixOS/nix/issues/12472#issuecomment-2662973140 | 23:31:10 |
| Robert Hensing (roberth) | another small benefit I forgot is that this way we don't have to install the C API libraries | 23:32:24 |
| Robert Hensing (roberth) | but the main motivations are in that thread | 23:32:36 |
| emily | fwiw, I don't think passthru.dev can really work fundamentally even if the .dev.dev thing was fixed, there are too many assumptions about things being actual outputs | 23:32:44 |
| emily | (while I'm here, is the nix/config.h header deprecated?) | 23:33:11 |
| Robert Hensing (roberth) | I have some code that seems to implement the multi output attribute interface correctly now | 23:33:31 |
| Robert Hensing (roberth) | I think so | 23:34:40 |
| emily | fwiw I think the "import the nix/ directory of the Nix repo" approach makes it much harder for regular Nixpkgs contributors to fix issues in the Nix packaging, since there is an entire layer of non-standard abstractions that mostly do not directly benefit Nixpkgs and diverge from its conventions; there's a reason we usually don't import other projects' Nix infrastructure wholesale when packaging them | 23:39:58 |
| emily | but my primary concern is just that currently it seems to break every downstream that uses Nix as a library | 23:40:17 |
| ElvishJerricco | I'm also still just not really seeing the actual use case... | 23:40:39 |
| emily | uh, also the components use lib.fileset somehow? | 23:42:58 |
| emily | which isn't meant to be allowed in Nixpkgs and I don't really understand how it's not breaking eval | 23:42:59 |
| emily | oh, I guess because it's dead code in the Nixpkgs context | 23:43:29 |
| ElvishJerricco | which itself is a problem | 23:44:44 |
| emily | libs.nix-store doesn't seem to work properly. nix/path.hh wants types.hh which is not in its include dir. | 23:44:58 |
| ElvishJerricco | the dead code made it much harder for me to understand what was going on | 23:45:00 |
| emily | (if it's part of another package it should be propagating that) | 23:45:11 |
| Robert Hensing (roberth) | I've opened https://github.com/NixOS/nixpkgs/pull/383508 | 23:52:12 |
| Robert Hensing (roberth) | I believe it fixes the .dev output | 23:52:45 |
| Robert Hensing (roberth) | IME the dev output propagates what you need, but I'd be happy to improve the individual libs.* packages | 23:55:29 |
