Roel Janssen skribis:
> 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
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 “b
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
Ludovic Courtès writes:
> Hi!
>
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> IIUC, (guix workflows) from the tarball you sent executes workflows in
>>> the current environment, as opposed to creating a derivation that would
>>> actually perform the workflow. What motivat
Hi!
Roel Janssen skribis:
> Ludovic Courtès writes:
[...]
>> IIUC, (guix workflows) from the tarball you sent executes workflows in
>> the current environment, as opposed to creating a derivation that would
>> actually perform the workflow. What motivated this approach?
>
> The short answer:
Ludovic Courtès writes:
> Roel Janssen skribis:
>
>> I realize I never shared my proof-of-concept implementation. I attached
>> my motivations for having a workflow language in Guix, and my code.
>
> Nice work, thanks for sharing!
>
>> The subcommand "guix workflow" does not work (yet) here. I
Roel Janssen skribis:
> I realize I never shared my proof-of-concept implementation. I attached
> my motivations for having a workflow language in Guix, and my code.
Nice work, thanks for sharing!
> The subcommand "guix workflow" does not work (yet) here. I currently
> execute a workflow dire
Hello all,
Thank you for your replies. I will use Ricardo's response to reply to.
Ricardo Wurmus writes:
> (Resending this as it could not be delivered.)
>
> Ricardo Wurmus writes:
>
>> Hi Roel,
>>
>>> With GNU Guix we are able to install programs to our machines with an
>>> amazing
>>> level
(Resending this as it could not be delivered.)
Ricardo Wurmus writes:
> Hi Roel,
>
>> With GNU Guix we are able to install programs to our machines with an amazing
>> level of control over the dependency graph of the programs. We can now know
>> what code will run when we invoke a program. We
Hello Guix!
Roel Janssen skribis:
> So, I would like to propose a new Guix subcommand and an extension to
> the package management language to add workflow management features.
>
> Would this be a feature you are interested in adding to GNU Guix?
I don’t know if it should be in Guix itself (and
Roel Janssen writes:
> The usage of a pipeline/workflow is somewhat different from the
> package construction, because we want to run the sequence of commands
> on different data sets (as opposed to running it on the same source
> code).
Is this not conceptually the same thing as changing the 's
Dear Guix,
With GNU Guix we are able to install programs to our machines with an amazing
level of control over the dependency graph of the programs. We can now know
what code will run when we invoke a program. We can now know what the impact
of an upgrade will be. And we can now safely roll-bac
12 matches
Mail list logo
