[FEATURE] Support Capturing Unspecified Options with **kwargs

[n2cholas]

Is your feature request related to a problem

I would like to capture arbitrary options passed by the user that are not specified in the function siguature. When using argparse, I could do args, unknown_args = parser.parse_known_args() and unknown_args would contain the unspecified options.

The solution you would like

To me, it makes sense to capture unspecified options in the **kwargs dict. For example,

# main.py
import typer

def main(name: str, **kwargs):
    print(kwargs)

if __name__ == "__main__":
    typer.run(main)

Here's how you use it:

python main.py Bob
> {}

python main.py Bob --height 170
> {'height': '170'}

python main.py Bob --last-name Foo --age 25
> {'last-name': 'Foo', 'age': '25'}

Since we don't specify the type of any of the **kwargs, they are captured as strings.

Describe alternatives you've considered

1. Currently, unspecified options will raise an error. Instead, you could give users the ability to ignore these errors, so they can access the rest of the arguments via sys.argv. This is inelegant, though.
2. You could also allow users to use *args to capture unspecified options. However, I don't know how to implement this robustly, especially when it's possible for existing options to be a list.
3. There is a hacky workaround that is currently possible to capture unspecified options:

# main.py
import typer
from typing import List

def main(name: str, kwargs: List[str], color: str = 'blue'):
    print(kwargs)

if __name__ == "__main__":
    typer.run(main)

python main.py Bob height 170
> ('height', '170')

python test.py Bob last-name Foo age 25 --color pink
> ('last-name', 'Foo', 'age', '25')

This has some drawbacks:

• different syntax for specified and unspecified args
• can't support sequences for options
• must always have at least one unspecified argument (otherwise you get an error)

Additional context

The release notes for 0.3.0 talk about functionality that seems relevant to this, but I was not able to find documentation for it (says it was merged in #120 by @teymour-aldridge ).

Thanks in advance!

[jessekrubin]

This would be super super nice.

[PetrochukM]

Using the underlying click library, I think this can be accomplished like so: https://click.palletsprojects.com/en/5.x/advanced/#forwarding-unknown-options
https://stackoverflow.com/questions/32944131/add-unspecified-options-to-cli-command-using-python-click
https://stackoverflow.com/questions/40002150/how-can-i-get-click-to-ignore-unknown-options-so-i-dont-have-to-define-pydevd-v

The click function can be included in typer, like so:
https://typer.tiangolo.com/tutorial/using-click/#including-a-click-app-in-a-typer-app

[PetrochukM]

Actually, I found support in typer for extra args:
https://typer.tiangolo.com/tutorial/commands/context/#configuring-the-context

[n2cholas]

That's perfect, thanks!

[tiangolo]

Thanks for the help @PetrochukM ! 🍰

And thanks for closing the issue @n2cholas ☕

Sorry for the long delay! 🙈 I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.

[mgamble]

As nice as this is, the solution pointed to by @PetrochukM is not quite perfect for my hopes and dreams. The drawback is the required use of typer.Context. I'm trying to write a typer application where the underlying functions are still usable within python. Needing to have the first argument be ctx: typer.Context in order to accept unspecified arguments is a big stumbling block toward that goal. Support for something like **kwargs: Annotated[dict[str,str], typer.Option()] = {} would be ideal. Baring that, I'll need to wrap the functions that use **kwargs into other functions that can use the ctx trick. That is a lot of copy/paste for complicated functions with many arguments, which seems a shame.