[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40549: More usability issues:
From: |
Ludovic Courtès |
Subject: |
bug#40549: More usability issues: |
Date: |
Tue, 12 May 2020 10:51:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi,
zimoun <address@hidden> 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’.
- bug#40549: More usability issues:, zimoun, 2020/05/11
- bug#40549: More usability issues:,
Ludovic Courtès <=
- bug#40549: More usability issues:, Tom Zander, 2020/05/12
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/12
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/12
- bug#40549: More usability issues:, zimoun, 2020/05/12
- bug#40549: More usability issues:, Tom Zander, 2020/05/13
- bug#40549: More usability issues:, Arne Babenhauserheide, 2020/05/13
- bug#40549: More usability issues:, zimoun, 2020/05/13
- bug#40549: More usability issues:, Arne Babenhauserheide, 2020/05/13