From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <875zh3w3yp.fsf@elephly.net> <8736c755xf.fsf@kyleam.com> <87y2tyv653.fsf@elephly.net> <877e16u081.fsf@elephly.net> In-Reply-To: <877e16u081.fsf@elephly.net> From: zimoun Date: Wed, 5 Feb 2020 15:34:16 +0100 Message-ID: Subject: Re: How to install GWL? Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To: Ricardo Wurmus Cc: Kyle Meyer , gwl-devel@gnu.org, =?UTF-8?Q?Ludovic_Court=C3=A8s?= List-ID: Hi Ricardo, On Sat, 1 Feb 2020 at 10:27, Ricardo Wurmus wrote: > When a user installs the GWL, the Guile module =E2=80=9C(guix scripts wor= kflow)=E2=80=9D > is installed. If the GUILE_LOAD_PATH is not set to include the > directory holding this module then the GWL won=E2=80=99t be available. L= et=E2=80=99s > 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 =E2=80=9Cguix workflow=E2=80=9D= sub-command to > whatever =E2=80=9Cguix=E2=80=9D command is invoked by the user. What abo= ut all of the > modules that the GWL uses? They also need to be on the load p I am thinking loudly. ath. The > =E2=80=9Cguix=E2=80=9D 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=E2= =80=99s > 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! Sorr= y. > 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. > 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? > (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 =E2=80=9Cguix pull=E2=80= =9D it is > possible that the GWL (installed by =E2=80=9Cguix install gwl=E2=80=9D) b= reaks due to > API changes in Guix or even due to changes to the dependencies of Guix = =E2=80=94 > 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=E2=80=99d like it to b= e. 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 =E2=80=9Cguix pull=E2=80=9D) 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=C3=A9ment and others were there so we should be able to reconstitute ;-)) All the best, simon