Fix: include sub-actions in tab completion

[matthewhughes934]

For commands like pip cache with sub-actions like remove, so that e.g. pip cache re<TAB> completes to pip cache remove.

All the existing commands that used such sub-actions followed the same approach for: using a dictionary of names to methods to run, so the implementation is just teaching the Command object about this mapping and using it in the autocompletion function.

There's no handling for the position of the argument, so e.g. pip cache re<TAB> and pip cache --user re<TAB> will both complete the final word to remove. This is mostly because it was simpler to implement like this, but also I think due to how optparse works such invocations are valid, e.g. pip config --user set global.timeout 60. Similarly, there's no duplication handling so pip cache remove re<TAB> will also complete.

This is a feature that may be simpler to implement, or just work out of the box, with some argument parsing libraries, but moving to another such library looks to be quite a bit of work (see discussion[1]).

I also took the opportunity to tighten some typing: dropping some use of Any

Link: #4659 [1]
Fixes: #13133

[matthewhughes934]

this list could probably be auto-generated from all commands with a non-empty handler_map but I just hard coded it for simplicity (read: laziness 🙃)

Needs more thought.

[sbidoul]

There's no handling for the position of the argument, so e.g. pip cache re<TAB> and pip cache --user re<TAB> will both complete the final word to remove. This is mostly because it was simpler to implement like this, but also I think due to how optparse works such invocations are valid, e.g. pip config --user set global.timeout 60. Similarly, there's no duplication handling so pip cache remove re<TAB> will also complete.

Do such limitation apply to the current completions for the main commands ? At first sight it seems they don't (at least pip cache ca<TAB> does not complete). So I'm not sure if possibly erroneous completions are better than no completion at all.

[matthewhughes934]

There's no handling for the position of the argument, so e.g. pip cache re<TAB> and pip cache --user re<TAB> will both complete the final word to remove. This is mostly because it was simpler to implement like this, but also I think due to how optparse works such invocations are valid, e.g. pip config --user set global.timeout 60. Similarly, there's no duplication handling so pip cache remove re<TAB> will also complete.

Do such limitation apply to the current completions for the main commands ? At first sight it seems they don't (at least pip cache ca<TAB> does not complete). So I'm not sure if possibly erroneous completions are better than no completion at all.

No, those limitations don't apply: for the sub-commands the completion behaviour is split:

• If a sub-command is present in any of the current words, present the completion for that sub-command, else
• Present all sub-commands as completion options

So the only time we present sub-commands as completion options is when we haven't already seen any sub-commands

The relevant code starts at

pip/src/pip/_internal/cli/autocompletion.py

Line 36 in bc553db

subcommand_name: Optional[str] = None

If we want to avoid the behaviour you mentioned in this change I think we can do something like:

        handler_names = subcommand.handler_map().keys()
        # present handler names as completion only if we haven't already seen any handler names
        if not any(name in cwords for name in handler_names):
            for handler_name in handler_names:
                if handler_name.startswith(current):
                    print(handler_name)

This comes with two edge cases I can think of:

• If you pass the name of a handler to an option, e.g. pip cache --log remove re<tab> (i.e. log the output to the file named remove ... for some reason) won't complete correctly. Off the top of my head I can only think of contrived examples to produce that behaviour
• It might not play nice if one handler's name was a substring of another, e.g. if there was pip cache list and pip cache lists, but currently there's no such conflicts (so this is only a concern for future extensions)