guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Workflow management with GNU Guix


From: Roel Janssen
Subject: Re: Workflow management with GNU Guix
Date: Fri, 28 Oct 2016 19:25:15 +0200
User-agent: mu4e 0.9.17; emacs 25.1.1

Ludovic Courtès writes:

> 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.

Ideally, we would do the equivalent of @code{guix environment
--container --ad-hoc --pure <packages>}  and execute the programs inside
the environment.  Unfortunately, that requires super user privileges as
well (for good reasons!).

It would be great to build this in though.. just for those who want to
do things properly and have the luxury of doing so...

I'll try to implement this in the upcoming week(s) so we have something
to try out.

Kind regards,
Roel Janssen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]