| 14 Mar 2025 |
 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 |
| Robert Hensing (roberth) | I think byte canonicity might not be a problem in this case, as long as clients in the builder don't try to do their own hashing, which they really don't need to when the endpoint returns the relevant hashes anyway | 15:30:37 |
