Re: How to install GWL?

[Ricardo Wurmus]

Roel Janssen <address@hidden> writes:

> This would require us to package GWL in such a way that it doesn't have
> Guix as one of its inputs.  Is that possible?

I don’t think so.  I suppose the only way to avoid having Guix as an
input is by installing the GWL as a channel when “guix pull” is run, but
that route is fraught with problems.  Guix is just *one* of a number of
inputs, and it is not clear how to install all of them via “guix pull” —
nor would that be desirable.

>> How should the GWL be installed for maximum convenience and
>> compatibility?  Does it make sense to install it as a channel so that
>> it
>> is tied to the user’s current version of Guix?  That would be pretty
>> awkward and less convenient than just typing “guix install gwl”.
>
> Or.. we merge the code from GWL into Guix, so it's automatically there;
> no install needed.
>
> I think the code is quite lightweight, and since it uses the Guix
> modules, it is somewhat tied to a specific version of Guix.
>
> What's the reason for not wanting GWL directly in Guix?

The code won’t remain lightweight forever.  The GWL may gain support for
more advanced caching of intermediate results through external
libraries; it may gain support for deployment to virtual machines in the
cloud (e.g. via Guile AWS); it may depend on (or include) grid engine
bindings to provide better support for cluster execution.  None of this
really belongs to Guix itself, which already has a very wide scope.

I’d rather see Guix move into the opposite direction and embrace
extensibility by providing a stable API for its core modules.  With the
GWL we have an opportunity to demonstrate how Guix can be extended
without having to actually be part of it.

--
Ricardo