[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Workflow management with GNU Guix
From: |
Ludovic Courtès |
Subject: |
Re: Workflow management with GNU Guix |
Date: |
Fri, 28 Oct 2016 17:27:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Roel Janssen <address@hidden> 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’.