| 14 Mar 2025 |
 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 |
| Robert Hensing (roberth) | * "Easy to talk to from any language" and simplicity are both requirements for this thing | 10:35:52 |
| Robert Hensing (roberth) | Writing to $out is simpler than anything that can create a drv graph, but I think it'd be rare to generate single derivations anyway. Anything you can do in that single derivation, you could probably also have done in the derivation that generated it. | 10:37:57 |
 raitobezarius | https://varlink.org/ | 13:37:33 |
| emily | is varlink any better than JSON for byte canonicity? | 14:51:30 |
| emily | or is that no longer a requirement? | 14:52:16 |
| emily | ah, I guess this is separate :) | 14:52:25 |
| emily | fwiw, (c) seems like the most elegant solution to me. | 14:55:05 |
| emily | though it's a bit weird to be able to chain it like that. | 14:55:32 |
| Robert Hensing (roberth) | Something does seem elegant about (c), putting this capability in its own separate derivation, but it isn't clear to me which is a better UX and whether there's differences in performance between the solutions, especially wrt binary cache roundtrips. I feel like (d) is closer to the "deep realisation" idea, but I don't know whether that's inconsequential, better or worse. | 15:29:24 |
