[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to m
From: |
zimoun |
Subject: |
[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@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
- [bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests, Ludovic Courtès, 2022/03/14
- [bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests, zimoun, 2022/03/15
- [bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests, Ludovic Courtès, 2022/03/15
- [bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests,
zimoun <=
- [bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests, Ludovic Courtès, 2022/03/15
- [bug#54393] [PATCH v2 0/3] Add '--export-manifest' to 'guix shell', Ludovic Courtès, 2022/03/31
- [bug#54393] [PATCH v2 1/3] packages: Add 'package-unique-version-prefix'., Ludovic Courtès, 2022/03/31
- [bug#54393] [PATCH v2 2/3] environment: Export 'load-manifest'., Ludovic Courtès, 2022/03/31
- [bug#54393] [PATCH v2 3/3] shell: Add '--export-manifest'., Ludovic Courtès, 2022/03/31
[bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests, Greg Hogan, 2022/03/15