!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

899 Members
For people hacking on the Nix package manager itself190 Servers

Load older messages


SenderMessageTime
15 Mar 2025
@aidetechbot:matrix.orgaidetechbot joined the room.02:58:14
@hurdpublic:pub.solar@hurdpublic:pub.solar left the room.04:11:29
@roberthensing:matrix.orgroberth 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
@roberthensing:matrix.orgroberth 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:matrix.redalder.orgmagic_rbWouldnt that mean that one couldnt generate a derivation with a tool that isnt nix?10:31:11
@magic_rb:matrix.redalder.orgmagic_rbdon't know how useful that is, but under the current design its possible10:31:23
@roberthensing:matrix.orgroberth 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
@roberthensing:matrix.orgroberthWhat 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 complexity10:34:28
@roberthensing:matrix.orgroberth"Easy to talk to from any language" and simplicity a both requirements for this thing10:35:08
@roberthensing:matrix.orgroberth* "Easy to talk to from any language" and simplicity are both requirements for this thing10:35:52
@roberthensing:matrix.orgroberth 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:matrix.orgraitobezarius https://varlink.org/ 13:37:33
@emilazy:matrix.orgemilyis varlink any better than JSON for byte canonicity?14:51:30
@emilazy:matrix.orgemilyor is that no longer a requirement?14:52:16
@emilazy:matrix.orgemilyah, I guess this is separate :)14:52:25
@emilazy:matrix.orgemilyfwiw, (c) seems like the most elegant solution to me.14:55:05
@emilazy:matrix.orgemilythough it's a bit weird to be able to chain it like that.14:55:32
@roberthensing:matrix.orgroberthSomething 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
@roberthensing:matrix.orgroberthI 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 anyway15:30:37
@roberthensing:matrix.orgroberthOnly the Nix implementations need to get this right, which seems feasible15:31:25
@emilazy:matrix.orgemily how does outputOf currently get represented in the derivation? 15:34:39
@roberthensing:matrix.orgroberthjust in the inputs. We use a semistructured ATerm for the derivation references field, and iirc store-path-shaped placeholders in the other attributes15:38:54
@emilazy:matrix.orgemily if the separate derivation is considered a problem, perhaps "join the output" could be a field on the .drv itself? 15:40:02
@emilazy:matrix.orgemily you would still need a cp derivation for the arbitrary case to reconstruct (c) though 15:40:12
@roberthensing:matrix.orgroberth 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
@roberthensing:matrix.orgroberth 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
@roberthensing:matrix.orgroberth * 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
@roberthensing:matrix.orgroberth * 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
@emilazy:matrix.orgemily

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
@emilazy:matrix.orgemilymy 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 anyway16:20:50

Show newer messages


Back to Room ListRoom Version: 6