Replace existing command about click-plugins HOT 1 CLOSED

@thedrow Looks like the answer is no. Using the included example PrintIt package as the example package that receives plugins I tried modifying PrintItBold to override the upper command:

$ pip install -e example/PrintIt
$ printit --help
Usage: printit [OPTIONS] COMMAND [ARGS]...

  Format and print file contents.

  For example:
  
      $ cat README.rst | printit lower

Options:
  --help  Show this message and exit.

Commands:
  lower  Convert to lower case.
  upper  Convert to upper case.

First I defined a new upper() function in example/PrintItBold/printit_bold/core.py

@click.command()
def upper():

    """
    Override.
    """
    
    click.echo("Override.")

Then I registered it as a plugin in example/PrintItBold/setup.py

upper=printit_bold.core:upper

Installing the plugin shows a new bold command as expected, however the upper command is from PrintIt and not PrintItBold.

$ pip install -e example/PrintItBold
$ printit --help
Usage: printit [OPTIONS] COMMAND [ARGS]...

  Format and print file contents.

  For example:
  
      $ cat README.rst | printit lower

Options:
  --help  Show this message and exit.

Commands:
  bold   † Warning: could not load plugin. See `printit bold --help`.
  lower  Convert to lower case.
  upper  Convert to upper case.

Removing the code defining the upper command does cause the new upper command to be exposed:

$ printit --help
Usage: printit [OPTIONS] COMMAND [ARGS]...

  Format and print file contents.

  For example:
  
      $ cat README.rst | printit lower

Options:
  --help  Show this message and exit.

Commands:
  bold   † Warning: could not load plugin. See `printit bold --help`.
  lower  Convert to lower case.
  upper  Override.

So this feature is feasible given that technically the parent command is overriding the plugin, but after stepping through this the current behavior seems correct. Preserving the parent commands offers consistency to all users and instead forces alternate command implementations to register themselves under new names. If a plugin overrides the parent command with the same help text but behaves differently then it could be difficult to identify exactly why the command is behaving differently. I can see this scenario happening:

• A user depends on a specific package with a specific command.
• They install some other package.
• That package has a dependency that the user did not explicitly install.
• The dependency overrides the CLI command that the user depends on.
• The CLI command may or may not clearly be different and may or may not provide drastically different behavior.

from click-plugins.