Re: Workflow management with GNU Guix

[ludo@gnu.org (Ludovic Courtès)]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:

[...]

>> So I guess that’s an argument in favor of the approach you chose.
>
> Can't a derivation write its output to some other place than the store?
> Maybe by running it "by hand"?

Yes, if you run it “by hand”, then you can tweak things as you see fit.

>> Fundamentally, a derivation just describes a command, its arguments, its
>> dependencies, its outputs, and its environment variables.
>>
>> So you’re right: you can very much run a derivation “by hand” instead of
>> letting the daemon do it on your behalf.  The only difference is that
>> you won’t have write access to the store.
>
> And that's fine, because we don't want to write the output to the store :).
>
> So, the workflow language should create a derivation, but then
> guix-daemon should not execute the derivation, but instead, the workflow
> execution engine can do it so it can avoid writing the output to the
> store.. right?

Right.  In addition to the snippet I gave, you’d need to set the
environment variables that are specified in the derivation.

For each output of the derivation, one environment variable is defined
that points to its /gnu/store/… file name.  So for instance, you’d also
need to do:

  (setenv "out" "/home/roel/something")

if you want to “redirect” the “out” output to a place that’s not its
normal place in the store.

With user namespaces, you could simply bind mount /home/roel/something
to /gnu/store/… in the process that runs the derivation builder, instead
using of the ‘setenv’ hack above.

Ludo’.