From mboxrd@z Thu Jan 1 00:00:00 1970 References: <875zh3w3yp.fsf@elephly.net> <8736c755xf.fsf@kyleam.com> <87y2tyv653.fsf@elephly.net> From: Ricardo Wurmus Subject: Re: How to install GWL? In-reply-to: <87y2tyv653.fsf@elephly.net> Date: Sat, 01 Feb 2020 10:26:54 +0100 Message-ID: <877e16u081.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Kyle Meyer Cc: gwl-devel@gnu.org, ludo@gnu.org List-ID: Ricardo Wurmus writes: > Kyle Meyer writes: > >> Hi Ricardo, >> >> Ricardo Wurmus 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=E2=80=99s current version of Guix? That would be p= retty >>> awkward and less convenient than just typing =E2=80=9Cguix install gwl= =E2=80=9D. >>> >>> 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 =E2=80= =9Cguix > repl=E2=80=9D and rely on the environment to give us the user=E2=80=99s c= urrent 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 =E2=80=9C(guix scripts workf= low)=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. Let= =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 s= ub-command to whatever =E2=80=9Cguix=E2=80=9D 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 =E2=80=9Cguix=E2=80=9D command arranges for its own modules to appear on th= e load path first. So when using the GWL with any version of Guix *that* variant=E2=80= =99s 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 =E2=80=94 and that might conflict with versions used in the GWL. The first takeaway is: we don=E2=80=99t actually need to use an inferior Gu= ix 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 =E2=80=9Cguix pull=E2=80= =9D it is possible that the GWL (installed by =E2=80=9Cguix install gwl=E2=80=9D) bre= aks 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 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 =E2=80=9Cguix pull=E2=80=9D) cannot gr= ow too large. -- Ricardo