[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gwl-devel] Next steps for the GWL

From: Kyle Meyer
Subject: Re: [gwl-devel] Next steps for the GWL
Date: Thu, 06 Jun 2019 11:07:55 -0400

Ricardo Wurmus <address@hidden> writes:

>> One of the things I'd love to do
>> with GWL is to make it play well with git-annex, something that would
>> almost certainly be too specific for GWL itself.


> I wonder what the protocol should look like.  Should a workflow
> explicitly request a “git annex” file or should it be up to the person
> running the workflow, i.e. when “git annex” has been configured to be
> the cache backend it would simply look up the declared input/output
> files there.

The latter is what I had in mind.  One benefit I see of leaving it up to
the configured backend is that it makes it easier to share a workflow
with someone that doesn't have/want the requirements for a particular

>>> * add support for executing processes in isolated environments
>>>   (containers) — this requires a better understanding of process inputs.


> This means that it can map file systems into the container and then run
> the process expression in that environment.
> One thing I’m not happy about is that I can only mount directories, and
> not individual files that have been declared as inputs.  I’d like to
> have more fine-grained access.

Right, limiting to the declared files makes sense.

With `docker run', you can give files to -v:

  % ls /tmp/ | wc -l
  % file /tmp/scratch
  /tmp/scratch: ASCII text
  % docker run -it --rm -v /tmp/scratch:/tmp/scratch busybox ls /tmp

It looks like using files works for `guix environment' too, which makes
me think that call-with-container can handle receiving files in MOUNT.

  % guix environment -C --ad-hoc coreutils -- ls /tmp | wc -l
  % guix environment -C --expose=/tmp/scratch=/tmp/scratch --ad-hoc coreutils 
-- ls /tmp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]