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: Kyle Meyer <kyle@kyleam.com>, gwl-devel@gnu.org
Subject: Re: [PATCH] workflow: Consider unspecified free inputs when checking cache.
Date: Tue, 25 Jun 2019 20:33:10 +0200	[thread overview]
Message-ID: <87imstseft.fsf@elephly.net> (raw)
In-Reply-To: <CAJ3okZ3tLoq-YcXoMvpjtRQTKV+W0DVDeHAH0h8-kChQ7fkjWQ@mail.gmail.com>


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

> On Tue, 25 Jun 2019 at 06:30, Kyle Meyer <kyle@kyleam.com> wrote:
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> > I’m not sure if we should keep picking
>> > inputs from the environment silently and by default, but your patch is
>> > anyway more correct than what we had before.
>>
>> Hmm, for my use case, taking free inputs from the file system based on
>> the current directory is the only method that I'm actually interested in
>> (i.e. I don't see myself having any use for --input).  Perhaps my
>> thinking is too shaped by make/snakemake, and I don't fully grasp the
>> approach GWL is trying to take.
>
> I am not sure to fully understand the issue and all the recent changes.
>
> One idea of GWL is to have a functional workflow: the
> multi-composition of functions/processes. And free inputs
> are--say--the argument of this function. Therefore, if you have many
> samples and you need to apply the same workflow, then you just apply
> the function to each sample with --input.

That’s right.

It’s also used for when you have a shared stash of input files
(e.g. genomes) and you simply want to inform the GWL about where those
files are and that they correspond to inputs in the workflow — without
having to copy them first.

For a complicated workflow with lots of inputs specifying inputs can be
really tedious.  For this reason the GWL will also pick up appropriately
named files in the current working directory.

My only concern is whether this dual behaviour should be the default or
if it should be switchable.  (E.g. passing “--pure” would force the user
to specify all inputs with “--input”.)

--
Ricardo

  reply	other threads:[~2019-06-25 18:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13  3:48 [PATCH] workflow: Consider unspecified free inputs when checking cache Kyle Meyer
2019-06-24 13:54 ` Ricardo Wurmus
2019-06-25  4:30   ` Kyle Meyer
2019-06-25 17:33     ` zimoun
2019-06-25 18:33       ` Ricardo Wurmus [this message]
2019-06-26  1:31       ` Kyle Meyer
2019-06-26  7:05         ` 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=87imstseft.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=gwl-devel@gnu.org \
    --cc=kyle@kyleam.com \
    --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).