Re: Next steps for the GWL

[Kyle Meyer <kyle@kyleam.com>]

Hi Ricardo,

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> My goals for the future (in no particular order) are as follows:

Thanks for sharing.  Looks very exciting!

> [...]
>
> * inversion of control: enable workflow designers to use the GWL as a
>   library, so that the “guix workflow” user interface does not need to
>   be used at all (see PiGx for an example).

Sounds like a good direction to go, and I imagine it'd facilitate
building wrappers that extend GWL.  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.  For example

  * Make data caching git-annex aware.  When deciding to recompute data
    files, GWL avoids computing the hash of data files, using scripts as
    the cheaper proxy, as you described in 87womnnjg0.fsf@elephly.net.
    But if the user is tracking data files with git-annex, getting the
    hash of data files becomes less expensive because we can ask
    git-annex for the hash it has already computed.

  * Support getting annex data files on demand (i.e. 'git annex get') if
    they are needed as inputs.

> * explore the use of inferiors — the GWL should be usable with any
>   version of Guix that may be installed, not just the version that was
>   used at compilation time.  Can we use “guix repl” and inferiors,
>   perhaps?

For my personal use, I'd almost always want to pin an analysis workflow
at a certain Guix version, so making it easy to use inferiors in the
workflow would be great.

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

This is another one I'm especially excited about.  Functionality-wise,
are you imagining essentially matching the options available for 'guix
environment --container ...'?

-- 
Kyle