Show HN: Trogon – An automatic TUI for command line apps (github.com)

This is really fun. I have an experimental branch of my sqlite-utils CLI tool (which has dozens of sub-commands) running with this now and it really did only take 6 lines of code - I'm treating Trogon as an optional dependency because people using my package as a Python library rather than a CLI tool may not want the extra installed components:

https://github.com/simonw/sqlite-utils/commit/ec12b780d5dcd6...

There's an animated GIF demo of the result here: https://github.com/simonw/sqlite-utils/issues/545#issuecomme...

    pipx install sqlite-utils

    sqlite-utils install trogon

    sqlite-utils tui

  pipx inject sqlite-utils trogon 

  pipx install 'sqlite-utils[tui]'

Significantly harder problem, but what would be of most interest for me is for a program to offer this interface to an unannotated program (which will always be the majority). `trogon ffmpeg` or what have you. Theoretically, command line help is structured in a way it should be possible to parse, but I have no doubt there are many many non-compliant implementations that exist. I suppose you could lean on man files when they exist.

Will you’re a legend. I’ve been loving all the work you and the team are doing on textualize. And thanks for doing a lot of dev in the open for us noobs to level up.

I think the most important piece here is standardizing a schema format for command line programs.

Once you have that (and it’s actually adopted) there are many possibilities. TUI/GUI is just one of them. Think autocomplete, type checking, discoverability...

Looks very nice! Does it also support default "apps" like, e.g., ls?

I love anything TUI related. I spent a lot of time last year making a TUI-over-the-wire protocol with a TUI browser.

It's somewhat related to this because it's generating a TUI dynamically based on an input schema coming over the wire via gRPC.

Would love any feedback http://uggly.bytester.net

> Command line apps reward repeated use, but they lack in discoverability.

The biggest thing preventing me from learning more CLI explained in one sentence, I'll definitely be looking into this.

How easy is it to get this to compose nicely with typer, which also sits on top of click? like, if i expose the command group to the decorator or something, will that work?

I want to use terminal, but everytime I type something I get presented with an adjacent form I can alternatively use. A cli command builder gui. Best of both worlds. Also should be web-based. And all output should be a searchable, sortable, groupable datagrid. Terminals really fall down in this department. I can't believe there isn't a terminal that does this yet. Like a Python notebook I guess.

This makes perfect sense and the “why” is spot on.

Can it generate bash completion scripts? eg:

    $ . <(fab --print-completion-script zsh)

to enable autocomplete for fab in zsh shell.

    eval "$(_SQLITE_UTILS_COMPLETE=zsh_source sqlite-utils)"

Is there a similar tool with GUI that would obviate the need to typecheck argument values and make selection an easy toggle from a structured list with help/tooltips right where you need them instead of in an inconvenient separate --help document?

While we're building Swagger/OpenAPI for CLIs, could we also please create typed/type-safe CLIs? I want to invoke command line tools like I invoke functions in my favorite programming language.

This looks interesting, I love Textual so I tried this with one of the apps I wrote:

https://gitlab.com/stavros/parachute

Unfortunately, it doesn't seem to work, failing to find the `cli.command()` function (a group function) after I decorate `cli()` with @tui...

if man pages and `--help` output were more formal definitions of CLIs, we could make a tool that creates a browsable version of every CLI command that has man pages and/or `--help` text.

For various reasons, I use the stdlib argparse library. Will this work with that?

Does anyone know what terminal is being used in the demo? It looks really clean.

This is great. I'm relatively comfortable with command lines, but I think people who reflexively respond with "RTFM" are completely wrong. There are few other parts of my life where reading a manual are necessary to start using a product. Being apathetic to users' needs (or deliberately hostile towards users) is frowned upon in almost every field.

This is exactly my current experiment on a personal project I'm working on, though I'm trying to create a Textual UI on a dynamic Python argparse CLI. Creating a Textual UI is non-trivial.

My tool uPlaybook[0] is kind of a CookieCutter [1] / Ansible [2] mashup, and the playbooks typically would have a number of "slots" you can configure to control the templating, like project name, license, if you want to "git init", that sort of thing.

It currently auto-generates a argparse interface, or it can interactively ask you those questions. But I've been working on a Textual UI as well. I chose argparse over Click largely because I want to work with minimal dependencies, and the Textual UI would be an optional dependency.

Going to have to check this guy out.

[0] https://github.com/linsomniac/uplaybook [1] https://cookiecutter.readthedocs.io/en/stable/ [2] https://www.ansible.com/

Cool project!

But, also, “What is old is new again”.

Back in the days of the mainframe and 3270 terminals, all of the commands were pretty much like this. There really was no command line. Rather, it was a screen of fields filled in by the operator and sent wholesale to the system.

Of course it did not end there. Most every Unix system had some kind of, effectively, “curses” based, full screen administration TUI. They were all pretty good for basic and intermediate tasks. I recall doing a lot of disk operations (partition, raid/striping, etc) just following prompts on these things.

Unix System V actually had a rather nice form and menu package you could use from scripts to do your own TUI just like the admin console they shipped.

Anyway, nice project. Just always interesting to watch stuff come around again.

I've used the python library gooey which seems to do the same thing. I like the ux of trogon

Awesome work, thank you Will. And that picture of Trogan... beautiful!

As others have mentioned, GPT is quite good at reading semi-structured data and producing a structured output. I find it is very effective to ask it to output in an already popular, domain specific format whenever possible. Let it use familiar idioms, instead of trying to coerce it to use a bespoke format.

So here's a simple attempt at taking the output of `black --help` and turning it into a python `argparse` script. You could feed the `--help` or man page for pretty much any command into GPT-4 with this sort of prompt and get an argparse script. It probably doesn't hurt that GPT-4 is already familiar with the argument syntax for all the popular cli tools.

You could then imagine executing the generated code against a faux-argparse library which instantiates the data structures you need to render a Trogon UI. Probably best to do this in an appropriate sandbox.

  $ black --help | aichat --model gpt-4 --prompt 'write a python program that uses argparse to *exactly* parse this tools command line'
  
  ```python
  import argparse
  import sys

  def main(args=None):
      parser = argparse.ArgumentParser(description="The uncompromising code formatter.")
      parser.add_argument("SRC", nargs="*", help="Source files to format")
      parser.add_argument("-c", "--code", type=str, help="Format the code passed in as a string.")
      parser.add_argument("-l", "--line-length", type=int, default=88, help="How many characters per line to allow. [default: 88]")
      parser.add_argument("-t", "--target-version", choices=["py33", "py34", "py35", "py36", "py37", "py38", "py39", "py310", "py311"], help="Python versions that should be supported by Black's output.")
      parser.add_argument("--pyi", action="store_true", help="Format all input files like typing stubs regardless of file extension (useful when piping source on standard input).")
      ...
      parser.add_argument("-h", "--help", action="help", help="Show this message and exit.")

      if args is None:
          args = sys.argv[1:]
      parsed_args = parser.parse_args(args)
      print(parsed_args)

  if __name__ == "__main__":
      main()
  ```
  This Python program uses argparse to parse the command line options for the Black code formatter. You can run this script and pass the command line arguments to see the parsed output.

I don't understand why is it more effective than the manual lookup... If a certain cli tool has hundreds of arguments from which I need certain 2, I would rather open documentation and man pages in the `less` tool rather than scroll an infinite form. If a certain cli tool has just the arguments I need, then I know all of them already (or I can recall em in a few seconds from ctrl+r)

What's with the AI generated bird? If you're going to name it Trogon, it should at least look like one.