bug#40549: More usability issues:

["Ludovic Courtès" <ludo@gnu.org>]

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