today I'm testing tyro for creating Python CLIs and I really like it. you add type declarations to your function, call

tyro.cli(your_func)

separately, and you're done. your original function is usable everywhere (unlike Click's decorated functions). your CLI function can be trivially declared as an entry point under

[project.scripts]

. it even has support for config objects created from data classes. wdyt?

Looks kind of similar to

typer

^was gonna say I've been using

typer

and it's pretty great. hadn't heard of

tyro

yeah

tyro

is very small, don't know how I even arrived there.

typer

looks indeed similar (I knew of it but have never used it). the problem I have is that seemingly some functionality requires you to create the FastAPI-like

app = typer.Typer()

and decorate the commands, which I want to avoid

I believe that impression is correct (at least it's what I've done)

currently working with typer and I'm strongly considering refactoring to click. The click syntax is more verbose but it has thorough docs and many past issues for reference. Typer wraps and extends in its own ways and requires you to some act directly on the underlying click object. the immediate benefit of typer is the integration with rich and colorama

I would argue we should all be using

argparse

now its in the standard library, especially with framework code its just one less dependency that we can avoid conflicting with

I have 4 problems with click: its questionable decision of raising a

SysError

to signal completion + its reliance on decorators make it very difficult to reuse CLI functions elsewhere (we've been suffering the consequences of this for years in Kedro - especially given that Databricks launches processes in a very peculiar way). the third one is that it's really difficult to do introspection on the parsed commands etc (something @Dmitry Sorokin suffered when working on our telemetry). the fourth is that its maintainer is excessively blunt IMHO (I fully acknowledge it's difficult to handle such a large number of open source projects though and that they don't owe me anything - but it surely affects my "purchasing" choices).

reliance on decorators make it very difficult to reuse CLI functions elsewhere

i'm seeing this pain using

prefect

task

and

flow

decorators too. my (intended) solution is going to be to define the bare functions in one module and then call the decorator like I would a normal function ie

task_to_run = prefect.task(function_to_run)

instead of using the decorator

@

syntax

@Iñigo Hidalgo sounds like Kedro nodes & pipelines 😬

it really does, that's basically where i got the inspiration to do things that way 😆