Suggest "Did you mean" for misspelled commands

[johnthagen]

Summary

It would be useful to end users of click CLI applications if when they misspelled CLI sub-commands they got a helpful Did you mean... error message in a similar way to when they misspell an @option name (e.g., --name).

Motivating Example

Consider the following example Click CLI app:

import click


@click.group()
def cli():
    pass


@cli.command()
@click.option("--name", "-n", default="World")
def greet(name: str) -> None:
    click.echo(f"Hello, {name}")


@cli.command()
@click.option("--name", "-n", default="Friend")
def farewell(name: str) -> None:
    click.echo(f"Goodbye, {name}")


if __name__ == "__main__":
    cli()

If the user misspells --name, they get a helpful Did you mean error message:

$ ./main.py greet --nme David 
Usage: main.py greet [OPTIONS]
Try 'main.py greet --help' for help.

Error: No such option: --nme Did you mean --name?

But if they misspell greet, they do not:

$ ./main.py gret --name David
Usage: main.py [OPTIONS] COMMAND [ARGS]...
Try 'main.py --help' for help.

Error: No such command 'gret'.

Test Environment

• Click 8.3.0
• Python 3.13.8

Related Work

• Use difflib for potential suggestions in cli error messages #1446
• use difflib for name suggestions in error messages #1455

[kdeldycke]

This feature is implemented by a third-party extension called Cloup. See the project unittests as a proof.

[johnthagen]

@kdeldycke Thanks for sharing.

I still personally advocate that this feature would be best implemented in Click itself. Adding another dependency with other features the user may not want, has drawbacks. Also, implementing this directly in Click, means downstream libraries like Typer would pick it up automatically.

[RC2215]

I just searched the open issues before creating a new one for that exact suggestion.
I also think this would be useful in Click, as we’ve implemented it in our custom group by overriding resolve_command.

[itsmiketorres]

Can someone clarify what this issue is asking for? Using the name demo it seems like this feature is already implemented, see image below.

see class NoSuchOption in /src/click/exceptions.py, last edited 4 years ago

[johnthagen]

@itsmiketorres It works for argument names (e.g., --count) but not for sub command names. See the example in the OP.

[itsmiketorres]

Thanks for clarifying @johnthagen. I agree with you that adding additional dependencies has its drawbacks. Either way this would be a great feature

[RC2215]

I’d be happy to work on a PR if the proposal is accepted.

[johnthagen]

I’d be happy to work on a PR if the proposal is accepted.

Probably a question for @Rowlando13 ?

[Rowlando13]

@RC2215 I am happy to have you work on the PR with some qualifications. Click is in a pretty bad way with regard to technical debt, so the PR will probably only be accepted if the implementation does not require digging around in the internals. If you do proceed with a PR make it again main. There will not be another bugfix release before 9.0. Also please document the current behavior and limitations before proceeding. That should be main against stable.

[RC2215]

@Rowlando13
I noticed that the error for 'No such option' is raised with the normalized option name, while for 'No such command,' it is raised with the original command name. What is the desired behavior for the command error?

[Rowlando13]

Just pick one, we can look at it when the pr is done.