Add aliases for commonly used commands

[dreua]

What's the problem this feature will solve?

As a software developer and package maintainer, I often install and remove software packages with different package managers. With pip I often run into this error:

$ pip3 remove pdfarranger
ERROR: unknown command "remove"

Describe the solution you'd like

Have a remove command that does exactly the same as uninstall.

Alternative Solutions

• Using bash's alias command is not easily possible because it can only match the main command (I can add an alias for pip in general but not for pip remove.)
• pip does not seem to provide a built in alias command like dnf has

Additional context

Package managers which use remove and don't know uninstall:

1. dnf/yum (they do have erase as an alias)
2. apt(-get)
3. pacman

Package managers which have both:

1. flatpak

[uranusjr]

Sounds reasonable. I’d suggest not listing the alias in help to avoid clutter, but having the alias itself is fine.

[gutsytechster]

How do we add an alias to a command? I am not sure about it.

[McSinyx]

IMHO it's as trivial as

diff --git a/src/pip/_internal/commands/__init__.py b/src/pip/_internal/commands/__init__.py
index 6825fa6e..defcf967 100644
--- a/src/pip/_internal/commands/__init__.py
+++ b/src/pip/_internal/commands/__init__.py
@@ -44,6 +44,10 @@ commands_dict = OrderedDict([
         'pip._internal.commands.uninstall', 'UninstallCommand',
         'Uninstall packages.',
     )),
+    ('remove', CommandInfo(
+        'pip._internal.commands.uninstall', 'UninstallCommand',
+        'Uninstall packages.',
+    )),
     ('freeze', CommandInfo(
         'pip._internal.commands.freeze', 'FreezeCommand',
         'Output installed packages in requirements format.',

I'm trying to work on this because I thought it's easy but had to come here to ask about testing strategy 😄

[gutsytechster]

Thanks, @McSinyx! Please go ahead, no issue :)

As for testing, the approach I can think of is to parametrize the tests which involve uninstall command with remove command as well. IMO, this would test all the cases involve with uninstall command.

[McSinyx]

parametrize the tests which involve uninstall command with remove command as well

That's brilliant (kudos to pytest devs for making little convenient things like this possible too). I'm a bit worried about redundancy but first class command may need first class supports.

[deveshks]

IMHO it's as trivial as

This might cause remove to be listed in pip help, which I think we want to avoid as per #8130 (comment)

$ pip help

Usage:   
  pip <command> [options]

Commands:
  install                     Install packages.
  download                    Download packages.
  uninstall                   Uninstall packages.
  remove                      Uninstall packages.
  freeze                      Output installed packages in requirements format.
  list                        List installed packages.
  show                        Show information about installed packages.
  check                       Verify installed packages have compatible dependencies.
  config                      Manage local and global configuration.
  search                      Search PyPI for packages.
  cache                       Inspect and manage pip's wheel cache.
  wheel                       Build wheels from your requirements.
  hash                        Compute hashes of package archives.
  completion                  A helper command used for command completion.
  debug                       Show information useful for debugging.
  help                        Show help for commands.

I was thinking along the lines of implementing get_alias_commands which looks for a mapping between alias and it's commands (in this case it will be remove -> install) and call it at https://github.com/pypa/pip/blob/master/src/pip/_internal/cli/main_parser.py#L87

[McSinyx]

@deveshks, thank you for the heads up, that looks like a much better idea.

[cjc7373]

Personally I on board with the alias command or some similar settings. (like what git has)

[pradyunsg]

I’d suggest not listing the alias in help to avoid clutter, but having the alias itself is fine.

I think if we're adding aliases, we definitely want them to be visible to the user via help. That said, we should avoid any amount of clutter that we can. So, I agree that just adding "remove" with the same CommandInfo as uninstall is not what we want to do here.

I'd say, we should aim to have a uniform and proper way to provide aliases to users, allowing for multiple aliases for multiple commands, such that it's not difficult to add another alias for a command (similar to how adding a command is a matter of manipulating a single list).

Of course, this means we'd have to get a bit more fancy with how our command parser works, figure out how help should know about the command names and all that... but I much prefer that to something more "bolted on" / invisible to the users.

I'd imagine aliases could look like this:

$ pip help

Usage:   
  pip <command> [options]

Commands:
  i, add, install             Install packages.
  download                    Download packages.
  u, rm, remove, uninstall    Uninstall packages.
  ...

Or... we could do what npm does in their docs/help:

npm install (with no args, in package dir)
[snip, bunch more examples]

aliases: npm i, npm add
common options: [snip]

---

Even though I'm using them in the example above... I'm a -1 on adding a "remove" alias for uninstall, without a counterpart "add" alias for install and... I'm a -0 on adding them both together. I don't know how useful this, on it's own, would be to the general audience of pip users. I'm personally a lot more interested in adding shorthands for "most common commands", like I hinted at in the example above, which would be similar to npm i.

All that said, there's also the risk of "too many ways to do the same thing", which... is really the last thing I'd want to start messing about with pip's CLI today. I think we should wait until we move away from optparse to something else (see #4659), where it's easier to do these things properly without adding significantly more technical debt / complexity to the fairly complex/fragile CLI setup we have today.