Open peterjc opened 2 days ago
Bonus example combining yapx 0.5.2 https://github.com/fresh2dev/yapx with rich-argparse:
from typing import Annotated
from rich_argparse import RichHelpFormatter
import yapx
def say_hello(
name: Annotated[
str, yapx.arg(help="Who or what to greet?", metavar="NAME")
] = "World",
):
print(f"Hello {name}")
yapx.run(say_hello, formatter_class=RichHelpFormatter)
(Minor bug in yapx which I will report - the horizontal rule from yapx is too wide for the terminal)
This is interesting to me as it combines visual improvements over plain argparse (thanks to rich-argparse) with a type annotation based API definition a bit like typer.
Update: You don't even need to use use RichHelpFormatter
explicitly, yapx
does this automatically if rich-argparse
is installed! See https://github.com/fresh2dev/yapx/issues/2
I have been very impressed with https://typer.tiangolo.com/ as an argparse alternative for three reasons:
rich-argparse
also doesrich-argparse
also doesclick
that it can't handleargparse
'snargs="+"
ornargs="*"
functionality https://docs.python.org/dev/library/argparse.html#nargs which some of my old code relies on.Given I am sticking with
argparse
to maintain an existing API, I'd like to see how far I can push on points (1) and (2) alone. Usingrich-argparse
out-of-the-box gives an immediate and very easy improvement by adding color the argparse output - thank you!Is extending
rich-argparse
to deviate further from the current formatting something you'd consider in-scope (to mimictyper
output or otherwise)?Example help output (point 1)
So
rich-argparse
makes the help text much nicer, but doesn't change the layout. Typer goes further with ASCII box art.Example error in command (point 2)
Again
rich-argparse
makes the help text nicer, but doesn't change the layout. Typer goes further with ASCII box art.Code for the above example
Demo using argparse only:
Demo using argparse with rich-argparse only:
Demo using typer: