From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:43248) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iucI3-0003yY-Hp for gwl-devel@gnu.org; Thu, 23 Jan 2020 08:12:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iucI2-0003XV-Cz for gwl-devel@gnu.org; Thu, 23 Jan 2020 08:12:55 -0500 References: <875zh3w3yp.fsf@elephly.net> From: Ricardo Wurmus Subject: Re: How to install GWL? In-reply-to: Date: Thu, 23 Jan 2020 14:12:41 +0100 Message-ID: <87tv4muxiu.fsf@elephly.net> MIME-Version: 1.0 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: Roel Janssen Cc: gwl-devel@gnu.org Roel Janssen writes: > This would require us to package GWL in such a way that it doesn't have > Guix as one of its inputs. Is that possible? I don=E2=80=99t think so. I suppose the only way to avoid having Guix as an input is by installing the GWL as a channel when =E2=80=9Cguix pull=E2=80= =9D is run, but that route is fraught with problems. Guix is just *one* of a number of inputs, and it is not clear how to install all of them via =E2=80=9Cguix pu= ll=E2=80=9D =E2=80=94 nor would that be desirable. >> 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 pr= etty >> awkward and less convenient than just typing =E2=80=9Cguix install gwl= =E2=80=9D. > > Or.. we merge the code from GWL into Guix, so it's automatically there; > no install needed. > > I think the code is quite lightweight, and since it uses the Guix > modules, it is somewhat tied to a specific version of Guix. > > What's the reason for not wanting GWL directly in Guix? The code won=E2=80=99t remain lightweight forever. The GWL may gain suppor= t for more advanced caching of intermediate results through external libraries; it may gain support for deployment to virtual machines in the cloud (e.g. via Guile AWS); it may depend on (or include) grid engine bindings to provide better support for cluster execution. None of this really belongs to Guix itself, which already has a very wide scope. I=E2=80=99d rather see Guix move into the opposite direction and embrace extensibility by providing a stable API for its core modules. With the GWL we have an opportunity to demonstrate how Guix can be extended without having to actually be part of it. -- Ricardo