GNU bug report logs - #54393
[PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Mon, 14 Mar 2022 21:51:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 54393 <at> debbugs.gnu.org
Subject: Re: bug#54393: [PATCH 0/2] Add 'guix manifest' to "translate"
 commands to manifests
Date: Tue, 15 Mar 2022 11:21:07 +0100
Hi,

On Tue, 15 Mar 2022 at 10:23, Ludovic Courtès <ludo <at> gnu.org> wrote:

> OTOH, sub-commands as just as cheap (and as expensive!) as command-line
> options.  That is, one way or another, we’ll have to maintain the thing,
> whether it’s called ‘--create-manifest’ or ‘manifest’.

I agree...

> To me, the argument in favor of the sub-command is that that it’s more
> discoverable, clearer, and easier to use.  A user who has a ‘guix shell’
> command line can replace ‘shell’ by ‘manifest’ and get their manifest.

...but I am not convinced. :-)  For instance, about discoverability,
assuming "guix install / remove" would not be an alias of "guix
package", then I would go va "guix help" then "guix install --help"
then probably via "guix help" again, then "guix remove --help" etc.
An extreme counter-example to your "clearer" point about subcommands
is Git: I do not consider such many subcommands more discoverable
because it gives the impression of a scattered mess.  Subcommands
provide a thematic hierarchy.  For sure, it is a balance. :-)  Because
Guix is doing many many things, it is hard for people to understand,
IMHO, therefore a sub-command hierarchy helps for catching the Guix
features... I digress. :-)

Well, my point is, for example, the logic of "guix system" then "guix
system <action> <--options>" appears to me easier to grasp and
discover.  Idem with "guix import".  I think "guix vm" or "guix image"
would not ease the discoverability.  What is unfortunate with "guix
package" is that <action> and <--option> are both using dash-dash.
Another story. :-)

I am not convinced that promoting a niche use-case would be a good
idea.  For what my opinion is worth.  Well, I trust your experience if
you think it is better.

> Thinking about it, another option would be to add an ‘--export-manifest’
> option to ‘guix shell’ instead.

Thinking about it, it would be the most coherent from my point of
view.  And idem for --export-channels, no?


Cheers,
simon




This bug report was last modified 3 years and 104 days ago.

Previous Next


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