Re: support for containers

[Ricardo Wurmus <rekado@elephly.net>]

zimoun <zimon.toutoune@gmail.com> writes:

> On Tue, 29 Jan 2019 at 12:46, Ricardo Wurmus <rekado@elephly.net> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>> > By inputs, do you mean data-inputs and package-inputs?
>>
>> Data inputs only.
>
> I understand that only the input files need to be part of the input hash.
> However, I do not know if the output hash need to also contain the
> tool hash and the input hash.
> Therefore, when chaining (an input is another output), the store
> should track the tools used, somehow.

Ah, I understand now.

> Maybe, it is what you are explaining with the quote: "we just hash the
> inputs leading up to the output, excluding the output itself".

Right, “inputs” is very vague at this point.  It should be derived from
the process and all of its data inputs (which are the result of other
processes).

As you can see this is analogous to Guix.  I’m not clear on how exactly
this should be accomplished, to be honest.  In Guix we have packages
referencing other packages directly (through inputs or through the build
system); this is all compiled down to derivations, which have clear
inputs and outputs.

In the GWL we have processes, which are linked through workflows.
Processes compile to derivations that build scripts and the inputs to
these derivations are only package derivations — no data inputs, because
they only become important when the generated scripts are executed.

We could start by assuming that the generated *script* of the current
process (which references a particular package profile) is an input to
the process’s output, as are the other data inputs, which have other
processes scripts as inputs.

We could thus cheaply hash the scripts — since they contain references
to the tools they use.

--
Ricardo