From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: Workflow management with GNU Guix Date: Fri, 28 Oct 2016 19:25:15 +0200 Message-ID: <877f8swflw.fsf@gnu.org> References: <87wpmzhdk2.fsf@gnu.org> <87wpmvyocy.fsf@gnu.org> <87wpgwimn3.fsf@gnu.org> <87wpgvs2nz.fsf@gnu.org> <87twbz9qi3.fsf@gnu.org> <87zilobonw.fsf@gnu.org> <874m3wh6yu.fsf@gnu.org> <87k2cs8pfe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0AtO-0007QM-Fs for guix-devel@gnu.org; Fri, 28 Oct 2016 13:24:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0AtL-0005rf-Ee for guix-devel@gnu.org; Fri, 28 Oct 2016 13:24:34 -0400 In-reply-to: <87k2cs8pfe.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Ludovic Courtès writes: > Roel Janssen 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 } 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