unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: zimoun <zimon.toutoune@gmail.com>
Cc: gwl-devel@gnu.org
Subject: Re: support for containers
Date: Tue, 29 Jan 2019 18:19:57 +0100	[thread overview]
Message-ID: <874l9rpeiq.fsf@elephly.net> (raw)
In-Reply-To: <CAJ3okZ03DTudrdpoD30VqvuWqK0iS8uUBjRPqisDrpGVQLvRiA@mail.gmail.com>


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

  reply	other threads:[~2019-01-30 13:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 23:03 support for containers Ricardo Wurmus
2019-01-29  9:38 ` Ricardo Wurmus
2019-01-29 10:39   ` zimoun
2019-01-29 11:46     ` Ricardo Wurmus
2019-01-29 14:29       ` zimoun
2019-01-29 17:19         ` Ricardo Wurmus [this message]
2019-01-29 21:52           ` zimoun
2019-01-29 23:16             ` Ricardo Wurmus
2019-01-30 10:17               ` zimoun
2019-01-30 12:46                 ` Ricardo Wurmus
2019-01-29 10:22 ` zimoun
2019-01-29 11:44   ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.guixwl.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874l9rpeiq.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=gwl-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).