TLDR: there is no "real" bug. :-) Just a choice to do and document it.
On Fri, 24 Apr 2020 at 10:28, zimoun <[email protected]> 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
