FEAT: The PIP command alias feature

[luiisp]

In many package managers there are abbreviations for certain commands that are too long to write and are written repeatedly. an example of this is npm where npm install can be abbreviated as npm i, and everything will work normally.

This makes development more efficient and was something pip was missing

My PR brings this functionality in a clear and scalable way, now it is possible to abbreviate commands

pip install can be used as pip i or pip add
pip list can be used as pip ls
pip uninstall can be used as pip un or pip rm

Risk assessment

Low.
Abbreviations are not new commands and do not replace existing commands. Only when a command is not recognized is it checked whether the unrecognized command is an abbreviation of a command. Ex (i -> install) if it is, it is understood as the command but if not, the flow continues normally

Before:

After:

everything is scalable and in the future more abbreviations can be made just by putting the name of the command and the abbreviation and a dict

More screenshots

[luiisp]

everything ready to be merged, could anyone review it to do the merge?

[pradyunsg]

Adding a x-ref to #8137 and #8130.

Could you confirm that --help lists the aliases as in #8137 as well as handles suggesting corrections with the alias on typoes?

[pradyunsg]

Also, for the future, please don't mention maintainers for a first review -- we tend to have a lot of notifications already and, in my case, this didn't really affect if/when I see this PR.

[luiisp]

Adding a x-ref to #8137 and #8130.

Could you confirm that --help lists the aliases as in #8137 as well as handles suggesting corrections with the alias on typoes?

Now the aliases are displayed with pip --help just as you suggested in #8130

Also from now on each command has the right to as many aliases as it wants

# This dict lists real command aliases from `commands_dict`
commands_aliases: Dict[str, List[str]] = {
    "install": ["i", "add"],
    "uninstall": ["u", "rm", "remove"],
    "list": ["ls"],
}

Update: Even though I don't agree, I added checks when there are typos, if you change your mind just ignore the commit 55585e2

As for the fix suggestions, I haven't implemented them yet, do you think something like this is really worth it? since it's not the actual command but just the nickname? In my opinion, corrections should only be reserved for exact command names because in addition to adding additional complexities, it can cause confusion about the real name of the command, for example if it is accidentally typed "in" it will probably point to "i" and not "install", this can cause confusion for those using it

[luiisp]

Added checks for typing errors

[luiisp]

When will this get a real review? I know I may appear to be in a hurry, but it turns out that the pip code is constantly changing and a PR can become obsolete in a short time...

[morotti]

When will this get a real review? I know I may appear to be in a hurry, but it turns out that the pip code is constantly changing and a PR can become obsolete in a short time...

(Not a pip maintainer but I can have a look)

Looking at the screenshot, I don't see a benefit in having 4 different ways to install/uninstall a package, all it will do is cause confusion to pip users.

There are about ~10M python developers. With this change, there won't be two guides or two developers who will agree on how to install a package. It's going to be a nightmare for training and for code reviews and for new developers learning python.

Besides, it will take 5+ years for changes merged in master to reach most distributions and end users.
During that time, people and guides online will start recommending pip commands using any of these new aliases, but the command will fail for users because they are not using the correct pip version. Every answer on stack overflow and assimilated will have to be tagged for a specific pip version, like the python 2 vs python 3 migration. ^^

[notatallshaw]

Looking at the screenshot, I don't see a benefit in having 4 different ways to install/uninstall a package, all it will do is cause confusion to pip users.

While personally I agree with this sentiment (I would be -0 on this idea), I think it's best to discuss this design choice in #8130 and have this discussion for PR implementation review.

[luiisp]

Is there a chance this will be merged someday? Can someone please review it?

[ichard26]

Is there a chance this will be merged someday?

Given the many differing viewpoints shared in the original issue, there is absolutely no guarantee that this will be merged, but I will try to take a look in the next week.