Re: How to install GWL?

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

Hi Ricardo,

On Sat, 1 Feb 2020 at 10:27, Ricardo Wurmus <rekado@elephly.net> wrote:

> When a user installs the GWL, the Guile module “(guix scripts workflow)”
> is installed.  If the GUILE_LOAD_PATH is not set to include the
> directory holding this module then the GWL won’t be available.  Let’s
> assume that GUILE_LOAD_PATH is in fact set to include the modules of the
> GWL and its Guile dependencies (including an old version of Guix).
>
> (guix scripts workflow) then provides the “guix workflow” sub-command to
> whatever “guix” command is invoked by the user.  What about all of the
> modules that the GWL uses?  They also need to be on the load p

I am thinking loudly.
ath.  The
> “guix” command arranges for its own modules to appear on the load path
> first.  So when using the GWL with any version of Guix *that* variant’s
> modules are going to be used.

Yes, it is what I have tried to spot out previously in the thread. :-)
Re-reading, I horribly worded it so it was not-understandable. My bad! Sorry.


> This also includes Guile JSON, guile-sqlite, Guile Gcrypt,
> Bytestructures, etc in versions that match the variant of Guix — and
> that might conflict with versions used in the GWL.

Oh!
This is annoying... and hard to fix because it is the classical
dependency hell we know.


> The first takeaway is: we don’t actually need to use an inferior Guix
> when all we want is for the GWL to use the current version of Guix.

Not all Guix, only the current version of the packages, right?


> (Adding support for inferiors is still a good idea, of course, because
> it makes workflows more flexible and reproducible.)
>
> The second takeaway is: when upgrading Guix with “guix pull” it is
> possible that the GWL (installed by “guix install gwl”) breaks due to
> API changes in Guix or even due to changes to the dependencies of Guix —
> such as the Guile JSON upgrade recently.
>
> This makes me think that extending Guix without some API *and*
> dependency guarantees is a bit more fragile than I’d like it to be.  On
> the other hand, the API has been rather stable in the past and there has
> only been one incompatible upgrade (that of Guile JSON) that might have
> affected the GWL.

Yes, but there is no guarantee, I mean it should work "almost" all the
time. I am not sure to agree that an "almost" remains.


> I still think that the channels feature is the wrong deployment
> mechanism for the GWL; I also still think that the GWL is too big to be
> a part of Guix proper.  Perhaps the GWL needs to add more runtime checks
> to ensure that the Guix modules it uses are available at runtime; any
> references to individual packages (such as the Guile variant to use to
> run scripts, or the Bash package used for shell wrappers) should also be
> replaced with more future-proof lookups by package name.

I thought you proposed that GWL should run in an inferior (say 1)
fixing the correct Guix version that it needs to work and another
inferior (say 2) should populate the store with any other Guix
version. And because the store is stable, then GWL using inferior 1
does the expected job. Is it not what you have in mind when speaking
about inferiors? (plural at inferior ;-))

Do I miss something?


> It would be desirable to have Guix releases more often, so that the
> difference between the version of Guix that was used to build it and the
> effective version at runtime (due to “guix pull”) cannot grow too large.

We had a session at Guix Days about improving the release process.
Well, I do not remind that someone took some notes. Sadly.
Let drop an email on guix-devel to collect the feedback (Chris
(Baines), Ludo, Clément and others were there so we should be able to
reconstitute ;-))


All the best,
simon