Support for argh

[johndoe46]

(Sorry if it's not the place to ask)

Is there any plan to support argh ? (https://pypi.org/project/argh/)

Thank you,

[mgaitan]

This is a very interesting topic. Similar projects such as Gooey or Wooey have the same limitation of origin, in that they are tied to CLIs implemented in a particular library (argparse in the case of those mentioned). For instance, see chriskiehl/Gooey#478

It would be great to have an abstraction layer that allows to define CLIs implemented in any framework (and language!) in a common format (like OpenAPI does for http API), and that these tools that "augment" the interface are based on that instead of the internal API of a particular framework. Then you could have these interfaces almost for free for any CLI app.

I only found this (somehow) related [discussion in HN](https://news.ycombinator.com/item?id=34960260.

[AndydeCleyre]

Yes, as someone who does not enjoy click, and does enjoy plumbum, I'm eager to learn what the plans are regarding different CLI toolkits going forward.

[simonw]

Working directly with argparse would be neat too - maybe something like this:

import argparse
from trogon import argparse_tui

parser = argparse.ArgumentParser(
    prog="ProgramName",
    description="What the program does",
    epilog="Text at the bottom of help"
)
parser.add_argument("filename")
parser.add_argument("-c", "--count")
parser.add_argument("-v", "--verbose", action="store_true")
argparse_tui(parser)

[mgaitan]

AFAIU we need to define an equivalent introspection function for each different cli library.

trogon/trogon/introspect.py

Line 95 in 42564c5

def introspect_click_app(app: BaseCommand) -> dict[CommandName, CommandSchema]:

The "abstract layer" I mentioned is covered by the dataclasses (CommandSchema, ArgumentSchema, etc) in that module.

Also, trogon should not depend by default on click, but import the library needed dynamically, depending to the function/class of the decorated CLI app.

[fresh2dev]

I was going to comment here, but I instead created an issue that was more generic; not specific to this one library:

#43

[daneah]

Given open or past issues and comments asking about support for at least:

• Typer
• argh
• argparse
• python-fire
• golang kong

It seems that #43 captures the more generally maintainable way forward.