unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: gwl-devel@gnu.org
Subject: Re: How to install GWL?
Date: Thu, 23 Jan 2020 02:17:15 +0100	[thread overview]
Message-ID: <CAJ3okZ0wLBMW8=Umqqt3-33Mp+WcTs8sVk-gxPRFp-r2UAYnTA@mail.gmail.com> (raw)
In-Reply-To: <875zh3w3yp.fsf@elephly.net>

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 <rekado@elephly.net> 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
B--.
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
reproducibility.


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

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

Cheers,
simon

  parent reply	other threads:[~2020-01-23  1:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22 21:55 How to install GWL? Ricardo Wurmus
2020-01-23  1:15 ` Kyle Meyer
2020-01-23 10:06   ` Ricardo Wurmus
2020-02-01  9:26     ` Ricardo Wurmus
2020-02-05 14:34       ` zimoun
2020-02-05 19:36         ` Ricardo Wurmus
2020-02-10  0:22           ` zimoun
2020-01-23  1:17 ` zimoun [this message]
2020-01-23 11:14 ` Roel Janssen
2020-01-23 11:24   ` zimoun
2020-01-23 13:02     ` Ricardo Wurmus
2020-01-23 14:18       ` zimoun
2020-01-23 13:12   ` Ricardo Wurmus
2020-01-31  9:16 ` zimoun
2020-01-31 11:07   ` Ricardo Wurmus
2020-02-01 11:49     ` Ludovic Courtès
2020-02-05 13:50       ` zimoun
2020-02-05 13:46     ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.guixwl.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ3okZ0wLBMW8=Umqqt3-33Mp+WcTs8sVk-gxPRFp-r2UAYnTA@mail.gmail.com' \
    --to=zimon.toutoune@gmail.com \
    --cc=gwl-devel@gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).