| 13 Mar 2025 |
 jade_ | its really badly documented but it is actually equivalent to --store internally; see my hastily scrawled notes on all env-vars used by cppnix derivatives https://docs.lix.systems/manual/lix/stable/contributing/testing.html?highlight=NIX_REMOTE#used-by-lix | 20:42:58 |
 John Ericson | You can also use just use NIX_CONFIG, the one env var to rule them all | 20:48:09 |
| jade_ | mhm | 20:49:55 |
| jade_ | it seems like sometimes env-vars get introduced like NIX_ABORT_ON_WARN which should just be more NIX_CONFIG | 20:51:35 |
| John Ericson | If they correspond to an option, yes | 20:55:44 |
| John Ericson | Btw, you should see what we just did to derivation goal | 20:55:58 |
| John Ericson | Even if you're gonna rewrite it in Rust anyways | 20:56:06 |
| 14 Mar 2025 |
| jade_ | yeah, NIX_ABORT_ON_WARN does, i am not sure why it was added; we caught this in code review of builtins.warn | 00:04:27 |
| John Ericson | No idea either | 04:20:24 |
 Robert Hensing (roberth) | Continuity with Nixpkgs lib.warn, and in turn the ability to produce a trace from the first warning encountered | 08:20:46 |
| Robert Hensing (roberth) | Could be deprecated I think | 08:22:02 |
 emily | the functionality is used by e.g. Nixpkgs release checks but I think the question is why it's an environment variable | 15:27:32 |
 magic_rb | Sounds like it should be a cli flag | 15:42:31 |
| jade_ | aaaaaaah this explains a lot as well as why it is not a CLI flag. okay. admissible I guesssssss, but bad.
IMO we should fix the release checks to set the nix config instead. | 16:44:20 |
| jade_ | * aaaaaaah this explains a lot as well as why it is not a CLI flag. okay. admissible I guesssssss, but bad.
IMO we should fix the release checks to set the nix config as well | 16:44:32 |
| emily | I mean it's nix-instantiate or whatever inside a Nix derivation | 16:46:19 |
| emily | so it could very much just use a flag instead | 16:46:22 |
| emily | but I think maybe it's the same environment variable that lib.warn looked at so yeah compat | 16:47:13 |
| jade_ | yeah, just needs to feature detect the nix implementation? | 16:47:16 |
| jade_ | right, yeah, compat with downstreams of nixpkgs, I guess. | 16:47:29 |
|  sinan changed their profile picture. | 17:49:47 |
| 15 Mar 2025 |
|  aidetechbot joined the room. | 02:58:14 |
|  @hurdpublic:pub.solar left the room. | 04:11:29 |
| Robert Hensing (roberth) | John Ericson: I think we should be returning deriving paths, not derivations from dyndrv generating drvs. https://github.com/NixOS/nix/issues/6316#issuecomment-2726414725 | 10:18:52 |
| Robert Hensing (roberth) | We'll need a mechanism for builders to return derivation graphs anyway for this to be useful (ie. the limited replacement that isn't recursive-nix), from which it follows that we'll have a mechanism to return derivation content. Reading derivation content from $out is then architecturally redundant, and, as I think I've shown, not quite good enough. | 10:21:57 |
| magic_rb | Wouldnt that mean that one couldnt generate a derivation with a tool that isnt nix? | 10:31:11 |
| magic_rb | don't know how useful that is, but under the current design its possible | 10:31:23 |
| Robert Hensing (roberth) | The thing that replaces recursive-nix should make that easy anyway. It shouldn't matter much whether you send your derivation content to a $out file or to a simple socket that returns the relevant store path for you | 10:33:34 |
| Robert Hensing (roberth) | What I have in mind is either a simple HTTP server or an even simpler Unix domain socket protocol that doesn't involve any of the daemon protocol complexity | 10:34:28 |
| Robert Hensing (roberth) | "Easy to talk to from any language" and simplicity a both requirements for this thing | 10:35:08 |
