From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Extending Guix without using the Guile load path Date: Thu, 12 Mar 2020 14:29:28 +0100 Message-ID: <871rpxu2fb.fsf@gnu.org> References: <87o8tulhci.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53210) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCNu0-0006GN-4N for guix-devel@gnu.org; Thu, 12 Mar 2020 09:29:32 -0400 In-Reply-To: <87o8tulhci.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 19 Feb 2020 16:36:13 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: Guix-devel Hello! Ricardo Wurmus skribis: > I think it=E2=80=99s a bit difficult to install the Guix Workflow Languag= e at > this point and I=E2=80=99d like to change that. > > Currently, new sub-commands for Guix are looked up by module name on the > Guile load path. When installing the =E2=80=9Cgwl=E2=80=9D package, thou= gh, the Guile > load path is not automatically altered, so users need to set it up by > themselves. The load path is only altered automatically when users > install the =E2=80=9Cguile=E2=80=9D package. This is not a good recommen= dation because > users may have Guile 2.2 in their profile, and not Guile 3.0 or whatever > version may be needed by the extension. > > I wonder if we can make this a little nicer by letting Guix look for > sub-command scripts in directories that are listed in an environment > variable, such as GUIX_EXTENSIONS_PATH. The =E2=80=9Cguix=E2=80=9D packa= ge would set > this search path and packages wanting to provide a sub-command (such as > =E2=80=9Cguix workflow=E2=80=9D or =E2=80=9Cguix home=E2=80=9D) would arr= ange to have their scripts > placed in that sub-directory of their outputs. > > What do you think? GUIX_EXTENSIONS_PATH sounds like a good idea. I suppose it could be implemented pretty much like GUIX_PACKAGE_PATH? That would also allow us to consider Guix Home a package rather than a channel, like you did for GWL. (Though eventually, I do think something like Guix Home should be part of Guix itself. :-)) Ludo=E2=80=99.