[Top][All Lists]

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

Re: How to install GWL?

From: zimoun
Subject: Re: How to install GWL?
Date: Thu, 23 Jan 2020 02:17:15 +0100

Hi Ricardo,

It is not clear in my mind and I have not looked at the code so my
words probably do not make sense.
Well, correct me if I am wrong. :-)

On Wed, 22 Jan 2020 at 22:56, Ricardo Wurmus <address@hidden> wrote:

> 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).

More precisely, GWL needs the Guix Scheme library to build; quickly
speaking the symbols under the folder 'guix/'.
Even if it remains some work, we can assume that the API is stable.

Well, the issue comes from the version of the toolchain used to build GWL.

Let consider the package definition of GWL depends on the
commit/version A of Guix.
And this GWL package lives in the Guix commit B.
So all the machinery -- Guile, compilers, bootstrap, Guix builders
themself -- will use the commit B to build GWL but will compile the
commit A of the Guix library.

My first question is: when running GWL in the state B, from which
commit will the packages come from? The packages defined in the
library --commit A-- _or_ the packages in the current state --commit
And if from commit A, which toolchain is used to build the packages:
the one from A or from B?

Currently, how is it working?

> 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”.

As a user, I expect that "guix workflow" uses all the packages in the
current Guix state I am. Because it is how all "guix <command>" works.

What I naively would think it works:

1. commit B
   $ guix install gwl
=> populate the store and compile GWL with the toolchain of the commit
B using the Scheme library at commit A (as an end-user I am not to ask
myself which version of the library :-)).

2. $ guix worklow <stuff>
=> use the packages and toolchain of commit B
i.e., the Guix living in ~/.config/guix/current

3. commit C
   $ guix pull

4. $ guix workflow <other-stuff>
=> recompile workflow with the Scheme library at the state C using the
toolchain of C and so add an entry to the store. Then use the packages
at C too.

Well, the version of the Scheme library does not matter so much. But
all the version of toolchain matter when speaking about

Considering classical packages, installing at commit B, then pulling,
then running is not confusing, I mean: after the pull, 'guix describe'
will return commit C and every 'guix <command>' will use this commit
C. And I know that if I use a package installed before the pull, then
I run the "old" version because I know that I need to upgrade to run
the new one. The confusion is the term 'guix' in 'guix workflow' so I
expect that the <command> 'namely workflow' acts as any other

An easy solution to fix this kind of confusion is to rename "guix
workflow" as simple "gwl"  or whatever else.

> 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.

It is too late to have a clear mind. :-)
My opinion is that rename "guix worklow" as simply "gwl" would ease
the installation and reproducibility process. Deal with GWL as any
other package.
And this "gwl" command would use the package of the current Guix state
including hypothetical channels.

For example, it would reduce the head itching when using "guix time-machine".

I am not sure if my input is relevant.

Thank you for raising up this and reactivate this mailing list. :-)


reply via email to

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