Re: How to install GWL?

[Ricardo Wurmus]

zimoun <address@hidden> writes:

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

I suppose we could work around this potential problem with an extra
step.  We provide the (guix scripts workflow) module, which Guix tries
to find, but it doesn’t mean that we have to keep the environment
untouched from then on.  That module could do all sorts of things
including the execution of a new Guile process with a suitable
environment.

But how would that affect the package versions that Guix provides if we
override the environment and essentially end up using an older Guix…?
We would then have to spawn an inferior Guix, which would really just be
the Guix that originally gave us control and not the one we’ve built
with…  But we can’t just use some Guix directory as an inferior —
there’s no support for that in (guix inferior), we need to go through a
derivation…

This sounds messy.

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

Right, but we do end up using modules from the current Guix, even though
these are not the modules we built with.

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

Oh, I didn’t think of inferior number 1 at all, but that’s a good
point.  We could arrange for the build-time modules of Guix to be made
available at runtime, independent of the version of Guix used to run
“guix workflow”.  Then we need to build packages with an inferior Guix,
which is identical to the Guix used to run “guix workflow”.

(guix inferior) does not allow us to do this yet.  The
gexp->derivation-in-inferior procedure requires a derivation that
returns some variant of Guix — we can’t just give it the directory name
of the invoking command.  I think this might be a good addition to (guix
inferior).

--
Ricardo