| 19 Feb 2025 |
 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 |
| emily | hm, why is it propagating the CLI package? | 23:58:34 |
| 20 Feb 2025 |
| Robert Hensing (roberth) | otherwise it didn't get picked up by nativeBuildInputs | 00:03:37 |
| Robert Hensing (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 |
| emily | is there a reason it couldn't just be: nix-whatever library packages in pkgs/by-name, the nix package symlinks everything and has bin, out, dev outputs? | 00:06:27 |
| emily | I don't see why the outputs need emulating at all – installing nix on a system would use nix.bin and only pull in the binary, nix.dev would be an actual output with all the relevant files symlinked, etc. | 00:06:53 |
