[FEATURE] Support Pydantic Models as ParamTypes

[sm-hawkfish]

Is your feature request related to a problem

I would like to use Pydantic Models as type annotations in my Typer CLI program.

The solution you would like

Typer would call Model.parse_raw on the string that was passed to the CLI

Describe alternatives you've considered

Rather than having Typer be so aware of the Pydantic API, I tried to create a custom click.ParamType that did the parsing, but even that did not work as custom types do not currently seem to be supported in the get_click_type function.

Additional context

Here's a simple example:

#!/usr/bin/env python3
import click
import typer
from pydantic import BaseModel


class User(BaseModel):
    id: int
    name = "Jane Doe"


class UserParamType(click.ParamType):
    def convert(self, value, param, ctx):
        return User.parse_raw(value)


USER = UserParamType()


def main(num: int, user: USER):
    print(num, type(num))
    print(user, type(user))


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

This currently throws:

Traceback (most recent call last):
  File "./typer_exp.py", line 26, in <module>
    typer.run(main)
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 848, in run
    app()
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 213, in __call__
    return get_command(self)()
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 238, in get_command
    click_command = get_command_from_info(typer_instance.registered_commands[0])
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 422, in get_command_from_info
    ) = get_params_convertors_ctx_param_name_from_function(command_info.callback)
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 403, in get_params_convertors_ctx_param_name_from_function
    click_param, convertor = get_click_param(param)
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 656, in get_click_param
    annotation=main_type, parameter_info=parameter_info
  File "/usr/local/lib/python3.7/site-packages/typer/main.py", line 586, in get_click_type
    raise RuntimeError(f"Type not yet supported: {annotation}")  # pragma no cover
RuntimeError: Type not yet supported: <__main__.UserParamType object at 0x7fc346234b10>

A major bonus would be if I could write the user: User type annotation directly, without creating the UserParamType.

Also - just want to say thank you for writing such an awesome python package and keep up the great work! 👏

[sm-hawkfish]

I just noticed that this is very similar to #77. I will leave this open and change the name to specifically request support for Pydantic in order to differentiate it.

[sm-hawkfish]

As proof of concept of how support for Pydantic Models could be implemented, I built on the monkey-patched version of get_click_type that @ananis25 wrote in #77:

#!/usr/bin/env python3
from typing import Any

import click
import pydantic
import typer


_get_click_type = typer.main.get_click_type


def supersede_get_click_type(
    *, annotation: Any, parameter_info: typer.main.ParameterInfo
) -> click.ParamType:
    if hasattr(annotation, "parse_raw"):

        class CustomParamType(click.ParamType):
            def convert(self, value, param, ctx):
                return annotation.parse_raw(value)

        return CustomParamType()
    else:
        return _get_click_type(annotation=annotation, parameter_info=parameter_info)


typer.main.get_click_type = supersede_get_click_type


class User(pydantic.BaseModel):
    id: int
    name = "Jane Doe"


def main(num: int, user: User):
    print(num, type(num))
    print(user, type(user))


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

$ ./typer_demo.py 1 '{"id": "2"}'

1 <class 'int'>
id=2 name='Jane Doe' <class '__main__.User'>

Also, Typer could settle on an API for custom types (e.g. in keeping with Pydantic, the Typer docs could declare "all custom ParamTypes must implement a parse_raw method") and this would then cover the use-case requested in #77 without needing to implement a registration process.

[ananis25]

Oh, I didn't know about the parse_raw method provided by pydantic. This is definitely neater than keeping a global container of custom datatypes!

The only reason to prefer a registration api imo is that the code not using pydantic types/classes can also be used in a CLI without making any changes to it.

For ex - the typer app.command function also only registers the function being decorated instead of wrapping it, which is useful if the method hello is defined somewhere you don't want to make edits.

import typer

def hello(name: str):
    return f"Hello {name}"

if __name__ == "__main__":
    app = typer.Typer()
    app.command()(hello)

[pypae]

+1
I really like the idea of using Pydantic models.
Another approach to parse_raw could be to traverse Pydantic models until we reach a supported type.
Parameters of type BaseModel could be parsed into multiple cli options like for example the traefik cli does.
This does only work for options and not for arguments.

#!/usr/bin/env python3

import click
import pydantic
import typer


class User(pydantic.BaseModel):
    id: int
    name: str = "Jane Doe"


def main(num: int, user: User):
    print(num, type(num))
    print(user, type(user))


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

The example above could then be called like this:

$ ./typer_demo.py 1 --user.id 2 --user.name "John Doe"

1 <class 'int'>
id=2 name='John Doe' <class '__main__.User'>

[martsa1]

I was about to write a ticket along the lines of @PatDue's comment above, I would love something along those lines; I currently have several methods with large, almost identical signatures, which map to a pydantic model.

Something like that would be fantastic!

[pypae]

Another approach to parse_raw could be to traverse Pydantic models until we reach a supported type.
Parameters of type BaseModel could be parsed into multiple cli options like for example the traefik cli does.
This does only work for options and not for arguments.

I'm working on a pull request to support this behaviour. Because there is no longer a 1-1 mapping between the typed function parameters and the click.Parameters, it involves quite a lot of changes.

Btw. @tiangolo how do you feel about this feature?

[jackric]

@tiangolo can we get this green-lighted for a pull request?

[mandarvaze]

Has anyone tried pydantic-cli ? though it uses argparse (from the README) rather than click

[liiight]

@tiangolo can we get this green-lighted for a pull request?

@jackric better to ask for forgiveness than permission 😉

[yashrathi-git]

This would also help many other use cases:

• I wanted to use, my own formatting for datetime, ex: today %H:%M, %M:%H(automatically uses date as today)
• typer would be able to serialize any custom object

It also doesn't seem, it would require a lot of changes on how typer works internally to implement this. There is already PR #304

[uniqueg]

Also would love to see this! Typer looks awesome, but I like to manage my configs with Pydantic, and I don't want to describe all my params twice. So currently looking at https://github.com/SupImDos/pydantic-argparse or https://pypi.org/project/pydantic-cli/ instead. But, alas, argparse...

Btw, just found this: https://medium.com/short-bits/typer-the-command-line-script-framework-you-should-use-de9d07109f54 🤔

[gkarg]

Going to try and implement this in #630, more or less exactly as described by @pypae