Support different CLI parser backends

[JulienGrv]

Hi Maintainers,

My issue sits between a question and a feature request.

I like what Typer brings to the table. Just like FastAPI, it makes intelligent use of type annotations. However, just like FastAPI, it is very opinionated regarding its dependencies (Pydantic).

I like Click and I'm sure that it can offer more than the built-in argparse library. However I think that the concept of Typer could also work using argparse.

And if so, then would you be willing to consider supporting different backends for Typer? Either Click or argparse and perhaps other ones in the future.

Best, Julien

[navhits]

I don't maintain. Although I liked your thought I'd like to differ. If you're looking to use argparse then why use Typer or Click in the first place? If Typer can work with argparse, there's no point extending click. I see Typer as an improvised bridge to click.

[JulienGrv]

I don't understand your comment. It seems you're mixing up things. Typer relies on Click to create the argument parser. My idea is to be less opinionated and offer argparse as an alternative.

[navhits]

I tried saying the same thing. Based on what you suggest, Typer will become another click or something big. Click implements its own parsing because of certain reasons as mentioned in their docs. This means Typer needs to handle such problems when using argparse. So an adapter design here might turn out to become a problem. It is just my opinion and if what you suggest will be implemented, it pretty sure would be great, because of the flexibility it can offer.

[JulienGrv]

Ok I understand now what you mean. Indeed argparse does not offer the flexibility of Click so using it means that some features will not be available or will require additional adaptations