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

Previous Next

Full log

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

From: 45mg <45mg.writes <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Simon Tournier
 <zimon.toutoune <at> gmail.com>, 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: Thu, 06 Feb 2025 17:00:33 +0000

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 :)

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.)

> 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.

> 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?

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.

> 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).

> -- 
> Thanks,
> Maxim

[1] https://yhetil.org/guix/20210105101817.7576-1-rekado <at> elephly.net/
    I /think/ this is the one?

Previous Next

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