| 15 Mar 2025 |
| aidetechbot joined the room. | 02:58:14 |
| @hurdpublic:pub.solar left the room. | 04:11:29 |
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 |
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 |
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 |
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 |
roberth | "Easy to talk to from any language" and simplicity a both requirements for this thing | 10:35:08 |
roberth | * "Easy to talk to from any language" and simplicity are both requirements for this thing | 10:35:52 |
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 |
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 |
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 |
roberth | Only the Nix implementations need to get this right, which seems feasible | 15:31:25 |
emily | how does outputOf currently get represented in the derivation? | 15:34:39 |
roberth | just in the inputs. We use a semistructured ATerm for the derivation references field, and iirc store-path-shaped placeholders in the other attributes | 15:38:54 |
emily | if the separate derivation is considered a problem, perhaps "join the output" could be a field on the .drv itself? | 15:40:02 |
emily | you would still need a cp derivation for the arbitrary case to reconstruct (c) though | 15:40:12 |
roberth | Not a fan of the Go types schema language, but otherwise it looks alright. Could be combined with JSON schema perhaps, via varlink's catch-all object | 15:42:50 |
roberth | That's sort of what I had in mind for (d), declare statically with an "advanced attr" that an output is a redirect (or may be a rewrite) and then the builder would write to $out or $outRewriteor something.echo $drv^out >$outRewrite` | 15:50:30 |
roberth | * That's sort of what I had in mind for (d), declare statically with an "advanced attr" that an output is a redirect (or may be a rewrite) and then the builder would write to $out or $outRewriteor something.echo $drv^out >$outRewrite\ | 15:50:41 |
roberth | * That's sort of what I had in mind for (d), declare statically with an "advanced attr" that an output is a redirect (or may be a rewrite) and then the builder would write to $out or $outRewriteor something.echo $drv^out >$outRewrite | 15:50:49 |
emily |
especially wrt binary cache roundtrips
the output of a join drv would be the actual final output, right? so if the output is cached no additional roundtrips? I may be misunderstanding though, is this when a cache has .drvs but no outputs? is that common?
| 16:20:06 |
emily | my feeling is that having a zillion tiny derivations should be made to be fast/good anyway because the more fancy incremental stuff you do the more you'll want that anyway | 16:20:50 |