bug#40549: More usability issues:

[zimoun <zimon.toutoune@gmail.com>]

TLDR: there is no "real" bug. :-)
Just a choice to do and document it.


On Fri, 24 Apr 2020 at 10:28, zimoun <zimon.toutoune@gmail.com> wrote:

>   guix package -I -A # does nothing
>   guix package -A -I # list available

Expected.

First line, -I -A' means that '-A' is seen as an argument for '-I'.
Idem for the second line '-A -I', i.e., '-I' is seen as an argument for '-A'.

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

One solution should be add short options as '-AA' or '-II' for such
cases.  But I am not convince that such "weird" combination deserves
such attention. :-)


Back to the initial report:

 (a) guix package -S 17 -d 18 # KO
 (b) guix package -d 18 -S 17 # OK

This is not the same issue than the one described previously.  Here
the culprit is 'process-actions'.  And composing "action" seems more
than legitimate (composing "query" is questionable).

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.


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.


My opinion based on backward compatibility argument is: let as it is
and document it in the manual.

WDYT?


All the best,
simon