From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:53273) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuR7i-0006wP-AW for gwl-devel@gnu.org; Wed, 22 Jan 2020 20:17:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuR7g-00078M-Te for gwl-devel@gnu.org; Wed, 22 Jan 2020 20:17:30 -0500 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]:44349) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iuR7g-00077y-NR for gwl-devel@gnu.org; Wed, 22 Jan 2020 20:17:28 -0500 Received: by mail-qt1-x841.google.com with SMTP id w8so1199059qts.11 for ; Wed, 22 Jan 2020 17:17:28 -0800 (PST) MIME-Version: 1.0 References: <875zh3w3yp.fsf@elephly.net> In-Reply-To: <875zh3w3yp.fsf@elephly.net> From: zimoun Date: Thu, 23 Jan 2020 02:17:15 +0100 Message-ID: Subject: Re: How to install GWL? Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gwl-devel-bounces+kyle=kyleam.com@gnu.org Sender: "gwl-devel" To: Ricardo Wurmus Cc: gwl-devel@gnu.org Hi Ricardo, It is not clear in my mind and I have not looked at the code so my words probably do not make sense. Well, correct me if I am wrong. :-) On Wed, 22 Jan 2020 at 22:56, Ricardo Wurmus wrote: > 1) it uses modules provided by Guix as one would use a library. These > include (guix gexp), (guix derivations), (guix monads), (guix store), > etc. > > 2) it uses Guix to install packages at runtime based on whatever > workflow a user asks to be run. > > The =E2=80=9Cgwl=E2=80=9D package has the =E2=80=9Cguix=E2=80=9D package = among its inputs due to 1). > This version of Guix will always be somewhat old, and older than the > version of Guix used to install the GWL. This is okay for using Guix > modules, but it wouldn=E2=80=99t be okay for 2). More precisely, GWL needs the Guix Scheme library to build; quickly speaking the symbols under the folder 'guix/'. Even if it remains some work, we can assume that the API is stable. Well, the issue comes from the version of the toolchain used to build GWL. Let consider the package definition of GWL depends on the commit/version A of Guix. And this GWL package lives in the Guix commit B. So all the machinery -- Guile, compilers, bootstrap, Guix builders themself -- will use the commit B to build GWL but will compile the commit A of the Guix library. My first question is: when running GWL in the state B, from which commit will the packages come from? The packages defined in the library --commit A-- _or_ the packages in the current state --commit B--. And if from commit A, which toolchain is used to build the packages: the one from A or from B? Currently, how is it working? > 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 pre= tty > awkward and less convenient than just typing =E2=80=9Cguix install gwl=E2= =80=9D. As a user, I expect that "guix workflow" uses all the packages in the current Guix state I am. Because it is how all "guix " works. What I naively would think it works: 1. commit B $ guix install gwl =3D> populate the store and compile GWL with the toolchain of the commit B using the Scheme library at commit A (as an end-user I am not to ask myself which version of the library :-)). 2. $ guix worklow =3D> use the packages and toolchain of commit B i.e., the Guix living in ~/.config/guix/current 3. commit C $ guix pull 4. $ guix workflow =3D> recompile workflow with the Scheme library at the state C using the toolchain of C and so add an entry to the store. Then use the packages at C too. Well, the version of the Scheme library does not matter so much. But all the version of toolchain matter when speaking about reproducibility. Considering classical packages, installing at commit B, then pulling, then running is not confusing, I mean: after the pull, 'guix describe' will return commit C and every 'guix ' will use this commit C. And I know that if I use a package installed before the pull, then I run the "old" version because I know that I need to upgrade to run the new one. The confusion is the term 'guix' in 'guix workflow' so I expect that the 'namely workflow' acts as any other . An easy solution to fix this kind of confusion is to rename "guix workflow" as simple "gwl" or whatever else. > 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. It is too late to have a clear mind. :-) My opinion is that rename "guix worklow" as simply "gwl" would ease the installation and reproducibility process. Deal with GWL as any other package. And this "gwl" command would use the package of the current Guix state including hypothetical channels. For example, it would reduce the head itching when using "guix time-machine= ". I am not sure if my input is relevant. Thank you for raising up this and reactivate this mailing list. :-) Cheers, simon