Roel Janssen <r...@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’.
