I know we are in semantics land now but most people would probably say that shelling out to another process doesn’t really constitute an integration. Put another way, you could just say that you could easily turn any CLI into a simple Python CLI with only a few lines of code with argparse itself, and that argparse supports any other CLI by just wrapping it, removing mentioning the Gooey part entirely. You’re essentially describing just the benefits and drawbacks of Python’s subprocess and argparse libraries at this point and not really saying anything about Gooey aside from the fact that it is argparse compatible.

In other words: “Hey look at this cool thing argparse can do, and because Gooey is basically api compatible with argparse, it can do it too!” And don’t get me wrong, I think Python’s expressiveness with the argparse library and in general its ability to make CLI’s in very few lines of code is great. But really the magic is argparse and Python in that regard.

> I know we are in semantics land now but most people would probably say that shelling out to another process doesn’t really constitute an integration.

Most people would be an exaggeration. Purists may think that, but the reality is most GUI wrappers use subprocessing.

While I agree that click integration would be nice, how would you turn any CLI tool to a GUI application without shelling out?

> But really the magic is argparse and Python in that regard.

True, but this is simply semantics. If I submit a PR to the Gooey project that lets you write a YAML configuration file to declaratively document the interface of a CLI tool, then automatically convert that config file to Python source, would that be any different? Is it because it's YAML you manually write and not Python? Or even something that uses ChatGPT to convert a man page to an argparse wrapper? The argparse is the trivial part. The real magic is Gooey.