https://kedro.org/ logo
#random
Title
# random
j

Juan Luis

03/11/2024, 8:57 PM
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?
👀 1
a

Arnaud Dhaene

03/11/2024, 9:26 PM
Looks kind of similar to
typer
c

Cody Peterson

03/11/2024, 9:31 PM
^was gonna say I've been using
typer
and it's pretty great. hadn't heard of
tyro
j

Juan Luis

03/11/2024, 9:35 PM
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
but this is an impression after quickly skimming through the docs, could be wrong
subcommands look more elegant in tyro to my eye https://brentyi.github.io/tyro/examples/02_nesting/05_subcommands_func/
c

Cody Peterson

03/11/2024, 9:37 PM
I believe that impression is correct (at least it's what I've done)
👍🏼 1
t

Thierry Jean

03/11/2024, 9:56 PM
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
d

datajoely

03/12/2024, 9:52 AM
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
👍 1
j

Juan Luis

03/12/2024, 10:17 AM
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).
👍 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
i

Iñigo Hidalgo

03/12/2024, 10:57 AM
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
j

Juan Luis

03/12/2024, 11:38 AM
@Iñigo Hidalgo sounds like Kedro nodes & pipelines 😬
😆 1
i

Iñigo Hidalgo

03/13/2024, 9:03 AM
it really does, that's basically where i got the inspiration to do things that way 😆
2 Views