Re: How to install GWL?

[zimoun <zimon.toutoune@gmail.com>]

Hi Ricardo,

(+Ludo)

Yesterday evening, I asked the Ludo's opinion about how to deal with
package that depends on Guix as a library.
So his is CC'd. In case, he wants to make an input. ;-)


On Wed, 22 Jan 2020 at 22:56, Ricardo Wurmus <rekado@elephly.net> wrote:

> the GWL is intended to be an extension of Guix.  It uses Guix in two
> ways:
>
> 1) it uses modules provided by Guix as one would use a library.  These
> include (guix gexp), (guix derivations), (guix monads), (guix store),
> etc.
>
> 2) it uses Guix to install packages at runtime based on whatever
> workflow a user asks to be run.
>
> The “gwl” package has the “guix” package among its inputs due to 1).
> This version of Guix will always be somewhat old, and older than the
> version of Guix used to install the GWL.  This is okay for using Guix
> modules, but it wouldn’t be okay for 2).
>
> 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”.
>
> If we stick with installing the workflow language as a package, how
> should package installation be handled?  Should all workflows require a
> channels definition for reproducibility, so that we could instantiate an
> inferior Guix using the exact specified version?  If none is provided we
> could fall back to the latest version of Guix.
>
> How does that sound?

The difference between "as a package" --which implies inferiors-- or
"as a channel" is: embed vs extend.

I was convinced that "as a package" was more convenient. Now I am not sure. :-)
Because we know what "embed" means. ;-)

For example, Julien's home-manager [1] uses the "as a channel" approach.


[1] https://framagit.org/tyreunom/guix-home-manager



All the best,
simon