Hi, zimoun 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’.