From: "Ludovic Courtès" <ludo@gnu.org>
To: zimoun <zimon.toutoune@gmail.com>
Cc: 40549@debbugs.gnu.org, Tom <tomz@freedommail.ch>
Subject: bug#40549: More usability issues:
Date: Tue, 12 May 2020 10:51:28 +0200 [thread overview]
Message-ID: <87mu6dcz8v.fsf@gnu.org> (raw)
In-Reply-To: <CAJ3okZ1QTgOB5Dqn4qR8A-Jrz0_Zkx5rJ247RFh5S6M6g06qbg@mail.gmail.com> (zimoun's message of "Tue, 12 May 2020 02:27:03 +0200")
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
>> --8<---------------cut here---------------start------------->8---> # OK
>> guix package --list-generations -p /path/to/profile
>> guix package --list-installed -p /path/to/profile
>>
>> # KO
>> guix package -l -p /path/to/profile
>> guix package -I -p /path/to/profile
>>
>> # OK
>> guix package -p /path/to/profile -l
>> guix package -p /path/to/profile -I
>>
>> # KO
>> guix package -l --profile=/path/to/profile
>>
>> # Do nothing
>> guix package -I --profile=/path/to/profile
>>
>> # OK
>> guix package -l --profile=/path/to/profile -l
>> guix package -I --profile=/path/to/profile -I
>> --8<---------------cut here---------------end--------------->8---
>
> All are expected too.
> Same reason. And the long option works because no argument is
> provided by '=' so it fallback to the default one "".
> Short options expect an argument so read the next characters as the
> value or fallback to the default one "" when there is no next
> character.
>
> Fixing this will add complexity on parsing 'args' when building
> 'opts'. Basically, "guix package -I -p /path/tp/profile" returns an
> error because the short option '-I' expect only one argument, read
> '-p' and then Guix cannot deals with the option '/path/to/profile' and
> so raises an error. See the dance with 'handle-argument' and
> 'arg-handler'. And "guix package -I '' -p /path/to/profile' works,
> obviously. Well, the extra quotes ('') is annoying but I am not
> convince that better could be done for short options -- regardless the
> order of CLI arguments.
Nothing new here, and everything is properly documented.
I think there are option parsers that “correctly” deal with the
ambiguity that arises for instance with “-I -p foo” (is ‘-p’ the
argument to ‘-I’ or something else?). Perhaps libc’s argp does it
right.
However (srfi srfi-37) does it as we see it now. Fixing it would mean
implementing a different option parser.
> Why (a) works and (b) not? Because the command-line is transformed
> into an alist. And this alist is built reading the command-line from
> right to left. Therefore, if you are on the generation 18 and you try
> to delete it, Guix raises an error which seems expected. The second
> one (b) works because first you switch and then you delete.
>
> Well, that's said, IMHO, two options:
>
> 1) the order of CLI does not matter;
> 2) the order of CLI matters.
>
> Well, the order of 'actions' necessary matters as it is seen with this
> example: "switch and then delete" does not end in the same state than
> "delete and then switch". Welcome in the classical mess of imperative
> package manager. ;-)
> Therefore, I am not convinced that something should be fixed. It
> comes from the very nature of 'actions': actions is not always
> commutative. Otherwise the best is to forbid to provide several
> actions with the same transaction; which seems a bad idea -- at least
> for me.
Right, but at least we could reverse the list returned by ‘args-fold’.
> However, main of us are used to read from left to right so it seems
> more natural to write:
>
> guix package --action1 --action2 # (a)
> than
> guix package --action2 --action1 # (b)
>
> in other words, the fix should be to simply 'reverse opts' and the CLI
> will read (a) instead of the current (b). My only concern is about
> backward compatibility.
We’ll need to check exactly what will behave differently. If the tests
don’t catch anything, I think we’re fine. Most likely, we’re talking
about corner cases like ‘-S x -d y’, which probably very few people
tried.
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-05-12 8:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 9:23 bug#40549: [usability] revert last generation Tom Zander via Bug reports for GNU Guix
2020-04-23 19:37 ` Ludovic Courtès
2020-04-23 19:51 ` bug#40549: More usability issues: Tom via Bug reports for GNU Guix
2020-04-24 8:28 ` zimoun
2020-05-12 0:27 ` zimoun
2020-05-12 8:51 ` Ludovic Courtès [this message]
2020-05-12 9:54 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 11:35 ` zimoun
2020-05-12 16:23 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 18:08 ` zimoun
2020-05-12 20:19 ` Tom Zander via Bug reports for GNU Guix
2020-05-12 21:38 ` zimoun
2020-05-13 6:22 ` Tom Zander via Bug reports for GNU Guix
2020-05-13 16:32 ` Arne Babenhauserheide
2020-05-13 18:02 ` zimoun
2020-05-13 18:53 ` Arne Babenhauserheide
2020-05-14 9:08 ` zimoun
2020-05-12 14:10 ` zimoun
2020-05-12 10:38 ` zimoun
2020-05-12 13:58 ` zimoun
2020-05-14 8:15 ` Efraim Flashner
2020-05-14 9:13 ` zimoun
2020-05-14 14:25 ` bug#40549: Fix -p profile -p profile -I zimoun
2020-05-12 13:03 ` bug#40549: proposal for 'process-actions' zimoun
2020-05-12 16:26 ` Tom Zander via Bug reports for GNU Guix
2021-09-08 12:49 ` bug#40549: [usability] revert last generation zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mu6dcz8v.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=40549@debbugs.gnu.org \
--cc=tomz@freedommail.ch \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.