GNU bug report logs - #75981
[PATCH (WIP) v1 0/4] Add 'guix fork'.

Previous Next

Full log

Message #77 received at 75981 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 45mg <45mg.writes <at> gmail.com>
Cc: Nicolas Graves <ngraves <at> ngraves.fr>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Tomas Volf <~@wolfsden.cz>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>, 75981 <at> debbugs.gnu.org,
 Ricardo Wurmus <rekado <at> elephly.net>, Attila Lendvai <attila <at> lendvai.name>,
 Simon Streit <simon <at> netpanic.org>
Subject: Re: [PATCH (WIP) v1.5 0/4] Add 'guix fork'.
Date: Fri, 07 Feb 2025 19:34:20 +0900

Hello!

45mg <45mg.writes <at> gmail.com> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Before you go further, I'd propose you to explore whether the
>> GUIX_EXTENSIONS_PATH mechanism could work for your new command.  If it
>> does, then that's even nicer,
>
> If I understand correctly how GUIX_EXTENSIONS_PATH is supposed to work,
> then yes, I could use it to get the Guix CLI to find my `fork`
> subcommand without it being in upstream Guix. But I'm trying to get it
> into upstream Guix, hence this patch series :)

Yes, that's the idea of extensions; they live as a separate
package/project that can be combined with Guix to extend it.

> Regarding /why/ I want it upstream - I've started a draft of a GCD in
> which I intend to make a comprehensive argument for its inclusion; I
> believe it's more useful and important than you'd think, and I hope I'll
> be able to convince you and everyone else of this.
>
> (May take me a while to finish the GCD, though.)

OK, I look forward to read it (and be convinced ;-)).

>> as I think in general it'd be preferable for something as particular
>> as 'guix fork' to not be advertised as a top level guix command.
>
> If that's specifically what you're worried about - Simon was of the
> opinion (upthread) that I should have made this a subcommand of `guix
> git`. So, we'd have `guix git fork create`, `guix git fork update`, etc.
> That would mean it wouldn't show up under top-level `guix --help`. WDYT?
> Would that work for you?
>
> I chose `guix fork` because AFAIK all our commands so far are at most 3
> 'verbs' long (eg. `guix system list-generations`), and 4 verbs felt a
> bit too much. But I'm flexible on this point.

If a Guix extension can do (and I think it should, since IIRC, extending
the available commands of the command line was the original goal of the
mechanism), then that's the best way to add a feature that, in my
opinion, should be the very last resort for users to extend Guix, as it:

1. Obfuscate the actual changes in the fork by rebasing upstream Guix
commits on top (bad for auditing it/security).

2. Can be more easily abused into doing anything nefarious to users
since it can touch any area of the Guix code (duh, it's a fork).

3. Could be easily (?) mistaken as the canonical/better way to
distribute changes made to Guix additions/improvements (instead of
contributing them upstream or via the extension mechanism of the use of
channels), especially if a prominent CLI command exists for it.

>> A note could be added to the manual pointing to this extension,
>> perhaps in a subsection of the section documenting channels, for the
>> rarer cases where this is useful/necessary.
>
> I don't really understand what you're proposing. Are you suggesting that
> we move guix/scripts/fork.scm and guix/scripts/fork/* to a separate
> directory from the other scripts, then ask people who want to use it to
> set GUIX_EXTENSIONS_PATH with that directory?

If this work here becomes a Guix extension, it'd live outside of Guix
itself in its main repository and be added as a package in Guix.  For
users, it'd be seemlessly picked up via the GUIX_EXTENSIONS_PATH search
path, which *should* be automatically set in a profile, according to
commit bbc1735be26 ("profiles: Implicitly set GUIX_EXTENSIONS_PATH.")).

> IMO, that'd just make it needlessly difficult to use it. And honestly,
> what exactly is the harm in having a lesser-used top-level subcommand?
> We have `guix refresh`, which the manual explicitly states is mostly
> only relevant for packagers.

Maintenance, crowding the manual, crowding the command line, and the
arguments I've mentioned above.

>> We'd also need to document the GUIX_EXTENSIONS_PATH environment
>> variable, and some usage guidance (I've never used an extension myself).
>
> Yup. Actually, this should be done regardless of what happens with my
> proposal. I had to search the mailing lists and track down the patch in
> which it was implemented [1] just to figure out what it was supposed to do
> (and even then I'm not entirely clear).

I think a good way to document it would be to show an example.  There's
already a 'guix-modules' Guix extension package available in Guix.

--8<---------------cut here---------------start------------->8---
$ guix shell guix guix-modules -- guix module --help
Usage: guix module COMMAND [OPTION]...
Provide an "environment module" interface for Guix.

Available commands:

    create    convert packages to module files
    
[...]
--8<---------------cut here---------------end--------------->8---

It seems the commit I've referenced above is not enough for the
GUIX_EXTENSIONS_PATH to be present, for some reason, which is why you
need to include the 'guix' package, whose package defines a search path
for it.  That's not optimal, but you can see how easy it is to use Guix
extensions.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.