today I'm testing <tyro> for creating Python CLIs ...
# random
today I'm testing tyro for creating Python CLIs and I really like it. you add type declarations to your function, call
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
. it even has support for config objects created from data classes. wdyt?
👀 1
Looks kind of similar to
^was gonna say I've been using
and it's pretty great. hadn't heard of
is very small, don't know how I even arrived there.
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
but this is an impression after quickly skimming through the docs, could be wrong
subcommands look more elegant in tyro to my eye
I believe that impression is correct (at least it's what I've done)
👍🏼 1
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
now its in the standard library, especially with framework code its just one less dependency that we can avoid conflicting with
👍 1
I have 4 problems with click: its questionable decision of raising a
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).
👍 1
💡 1
the Kedro CLI is tightly coupled with Click though, we're doing lots of fancy stuff around it. decoupling from it is not even on the table at the moment. this was just for a personal project 😁
👍 1
reliance on decorators make it very difficult to reuse CLI functions elsewhere
i'm seeing this pain using
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
@Iñigo Hidalgo sounds like Kedro nodes & pipelines 😬
😆 1
it really does, that's basically where i got the inspiration to do things that way 😆