Best practices for running commands in debugger

[austinhallett]

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 Typer documentation, with the integrated search.
• I already searched in Google "How to X in Typer" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to Typer but to Click.

Commit to Help

• I commit to help with one of those options 👆

Example Code

import typer
from services import example_handler_func

@cli.command()
def test_command(
    example_arg1: Optional[str] = typer.Option(
        "this is a default string", "--example-arg1", "-E1", help="example argument #1"
    ),
    example_arg2: Optional[str] = typer.Option(
        "this is a default string", "--example-arg2", "-E2", help="example argument #2"
    ),
):
    example_handler_func(example_arg1, example_arg2)

if __name__ == "__main__":
    test_command()

Description

The problem with the above code is that the when running it this way, as one may do for debugging purposes, the default arguments are not evaluated to their raw value, but instead are instances of the typer.Option object which will break any logic within the command function that expects a string.

I understand one alternative is to use typer.run(test_command) however with this option, you are unable to provide any arguments.

So my question is really what are the best practices for running commands within the debugger in which both default arguments work, and I am able to pass in arguments as well

Operating System

macOS

Operating System Details

No response

Typer Version

0.9.0

Python Version

3.11.2

Additional Context

No response

[Ultroncn]

The important change is to enter through Typer's parser, rather than calling the decorated Python function directly:

if __name__ == "__main__":
    cli()

Your test_command() call is an ordinary Python call, so an omitted argument keeps its actual Python default: the OptionInfo returned by typer.Option(...). The decorator doesn't wrap the function to parse CLI arguments on direct calls.

You can pass arguments in the debugger's launch configuration, e.g. in VS Code:

{
  "name": "Debug CLI",
  "type": "debugpy",
  "request": "launch",
  "program": "${workspaceFolder}/main.py",
  "args": ["--example-arg1", "from debugger"],
  "console": "integratedTerminal"
}

With just one registered command and no callback/subgroups, Typer promotes it to the root command, so this example does not include test-command in args. A multi-command app would include the subcommand name.

For a fixed local debugging harness, you can also explicitly invoke the parser:

cli(args=["--example-arg1", "from debugger"], standalone_mode=False)
# Or, to check all parsed defaults:
cli(args=[], standalone_mode=False)

typer.run(test_command) also accepts arguments from the process command line/debugger; you don't pass them as a second argument to typer.run itself.

I checked your two string-option defaults and the explicit --example-arg1 case on Typer 0.9.0 / Click 8.1.8, and again on Typer 0.27.3. In both cases the parser passed plain strings to the handler. The debugger launch configuration itself was not run.