"Did you mean ...?" for misplaced options

[BenjyWiener]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the documentation, with the integrated search.
• I already searched in Google "How to X" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.

Example Code

import logging

import typer


logger = logging.getLogger(__name__)

app = typer.Typer()


@app.callback()
def callback(debug: bool = False) -> None:
    if debug:
        logging.basicConfig(level=logging.DEBUG)


@app.command()
def run() -> None:
    logger.debug('Running...')
    print('Hello, World!')


if __name__ == '__main__':
    app()

Description

Passing an option in the wrong position (ex: passing a callback option after a subcommand) currently displays No such option: --name. This can be confusing, especially since many command line argument parsers allow options anywhere (including Python's built-in argparse).

I currently use a custom exception handler that catches click.NoSuchOption, and then traverses ctx to see if any of the parent commands have a matching option. If so, it adds a Did you mean section indicating the proper option placement:

python3 example.py run --debug

Usage: example.py run [OPTIONS]
Try 'example.py run --help' for help.
╭─ Error ──────────────────────────────────────────────────────╮
│ No such option '--debug' for subcommand: example.py run      │
│ Did you mean: example.py --debug run?                        │
╰──────────────────────────────────────────────────────────────╯

Due to the click vendoring, this is no longer possible without accessing _click, so I'd like to suggest adding this to typer itself. (Happy to open a PR.)

Operating System

Other

Operating System Details

No response

Project Version

0.27.3

Python Version

No response

Additional Context

#1832 (reply in thread)

[LeandroCustodio2002]

+1, this would be really nice. And since Typer now owns the vendored Click code, the hook point is pretty contained, so it seems like a good PR candidate.

Where the current message comes from

In typer/_click/parser.py, _match_long_opt raises:

if opt not in self._long_opt:
    from difflib import get_close_matches

    possibilities = get_close_matches(opt, self._long_opt)
    raise NoSuchOption(opt, possibilities=possibilities, ctx=self.ctx)

So the existing "Possible options: ..." hint only looks at the options of the current command, which is why --debug after run gives no hint at all. The short-option path (_match_short_opt) raises NoSuchOption(opt, ctx=self.ctx) with no suggestions at all.

What the change could look like

Both raise sites already have self.ctx, so they can walk up the parents and see if the option belongs to one of them:

def _find_owner_of_option(opt, ctx):
    parent = ctx.parent if ctx else None
    while parent is not None:
        for param in parent.command.get_params(parent):
            if opt in param.opts or opt in getattr(param, "secondary_opts", []):
                return parent
        parent = parent.parent
    return None

and when it finds one, build the hint from the command paths:

No such option '--debug' for 'example.py run'.
'--debug' is an option of 'example.py', put it before the subcommand: example.py --debug run

A couple of details worth handling in a PR:

• check secondary_opts too, so --no-debug (generated for bool flags) gets the hint
• do it for short options as well (-d after the subcommand)
• keep the existing "Possible options" suggestion when there's no parent match, so typo help doesn't regress
• rich_utils.rich_format_error already prints e.format_message(), so putting the hint into the exception message should be enough for both the rich and the plain output

Since you already have a working handler and offered to open a PR, I'd go for it and link this discussion. A small PR with tests for nested groups (app → sub-group → command) should be easy to review.

[svlandeg]

Thanks both!

The internals of passing context etc might still change in the upcoming refactors, so I would wait until those refactors are settled before considering a PR on this.