| 19 Feb 2025 |
 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 |
 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 |
| roberth | I'll refer to here https://github.com/NixOS/nix/issues/12472#issuecomment-2662973140 | 23:31:10 |
| roberth | another small benefit I forgot is that this way we don't have to install the C API libraries | 23:32:24 |
| 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 |
| roberth | I have some code that seems to implement the multi output attribute interface correctly now | 23:33:31 |
| 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 |
| roberth | I've opened https://github.com/NixOS/nixpkgs/pull/383508 | 23:52:12 |
| roberth | I believe it fixes the .dev output | 23:52:45 |
| roberth | IME the dev output propagates what you need, but I'd be happy to improve the individual libs.* packages | 23:55:29 |
| emily | hm, why is it propagating the CLI package? | 23:58:34 |
| 20 Feb 2025 |
| roberth | otherwise it didn't get picked up by nativeBuildInputs | 00:03:37 |
| roberth | I'm not sure this is the best solution | 00:03:51 |
| emily | i feel the split-lib packaging could probably use more time to bake before being unleashed into Nixpkgs… :) | 00:05:20 |
| emily | the level of packaging complexity seems very high and I'm not really sure why, we package a lot of multi-lib projects with much more mundane tooling than this | 00:05:38 |
