From mboxrd@z Thu Jan 1 00:00:00 1970 References: <875zh3w3yp.fsf@elephly.net> <8736c755xf.fsf@kyleam.com> <87y2tyv653.fsf@elephly.net> <877e16u081.fsf@elephly.net> From: Ricardo Wurmus Subject: Re: How to install GWL? In-reply-to: Date: Wed, 05 Feb 2020 20:36:27 +0100 Message-ID: <877e10rflw.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: zimoun Cc: Kyle Meyer , gwl-devel@gnu.org, Ludovic =?utf-8?Q?Cou?= =?utf-8?Q?rt=C3=A8s?= List-ID: zimoun writes: >> This also includes Guile JSON, guile-sqlite, Guile Gcrypt, >> Bytestructures, etc in versions that match the variant of Guix =E2=80=94= 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=E2=80=99t 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=E2=80= =A6? 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=E2=80=99ve built with=E2=80=A6 But we can=E2=80=99t just use some Guix directory as an infe= rior =E2=80=94 there=E2=80=99s no support for that in (guix inferior), we need to go throu= gh a derivation=E2=80=A6 This sounds messy. >> The first takeaway is: we don=E2=80=99t 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=E2=80=99t think of inferior number 1 at all, but that=E2=80=99s = 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 =E2=80=9Cguix workflow=E2=80=9D. Then we need to build packages with an in= ferior Guix, which is identical to the Guix used to run =E2=80=9Cguix workflow=E2=80=9D. (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 =E2=80=94 we can=E2=80=99t just give it the di= rectory name of the invoking command. I think this might be a good addition to (guix inferior). -- Ricardo