Re: How to install GWL?

[Ricardo Wurmus <rekado@elephly.net>]

Ricardo Wurmus <rekado@elephly.net> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>> Hi Ricardo,
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> 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 last combination sounds good to me: support/encourage specifying the
>> channel definition in the workflow, and fall back to the latest version
>> of Guix.  Though perhaps it'd be better to fall back to the user's
>> current version instead?  My thinking is that the user's version would
>> be a less frequently moving target, be more likely to have higher
>> substitute availability, and would more closely match any debugging and
>> testing the user is doing with, say, `guix environment'.
>
> Yes, I agree.  I suppose we could achieve this by simply spawning “guix
> repl” and rely on the environment to give us the user’s current version
> of Guix.  Then we connect to the spawned REPL.

This is all more confusing than I thought.

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

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.

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

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.

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.

--
Ricardo