A quick reply to some of the comments about argparse. Gooey is super old at this point. Argparse was a solid choice at the time when Gooey started. These days, Gooey itself speaks in JSON and is decoupled from argparse itself. However, argparse remains the main "blessed" interface (mostly because nobody else has built a different one).

Some fun FYIs: You can also invoke any arbitrary executable[0], not just python, which is pretty handy.

Re: last commit being 2 years ago. It gets harder to justify working for free on niche software as you get older and priorities change :( If it's any consolation, I DO feel guilty all the time. I have no idea why, but where I live, there's "GOOEY" graffiti tagged all over the place, so it's a nice ever-present reminder of the issue tracker that's currently going unloved. haha.

[0] https://chriskiehl.com/article/gooey-as-a-universal-frontend

I have a program I'm working on right now that does user-initiated argument parsing, and argparse is a great fit for it. I'd love to have a text-based UI as an option to drop users into, but Textualize requires Click (IIRC), and using Textual directly in my code to create the UI I've spent hours on and had absolutely no luck even getting started.

Overall I have found it to be very much not worth it adding typer as a dependency. Hard pass.

Saying 'our programable interface is the gui, use autohotkey' is fine, as long as you properly document all click regions.

This would be a massive productivity boost to anyone using such tools. It would also be great for disabled people.

ha ha

No way, especially because all the people taking most market-business-related decisions (eg which software to buy) are not tech-oriented. If we had more power on these decisions, that would mean that development, and even advertising of products, would be closer to what the parent comment suggest. But alas.

Markets cannot regulate nuanced behavior like this. Microsoft is a trivial example of anti-user practices and generally garbage design nonetheless being adopted due to their tremendous efforts of corporate propaganda and scaremongering the decision makers about their products.

The security implications of this give me heart palpitations.

To expose this "local API" usefully, you must either:

1. Share memory with other processes (new attack vector), or 2. Listen on some kind of network or native socket for messages and authn+authz the commands that come through it based on some security protocol (new attack vector).

The value proposition of an API is to allow control and data flow between an application and some external entity. It seems to me that it has security implications by definition.

This sounds cool. I saw the headline and before clicking anything, my first thought was "bet this heavily depends on argparse", so this is surprising - in a very nice way.

I'm a hardcore getopt fan, mostly because I believe the developer's convenience is nowhere as important as the convenience of the user, and the user shouldn't need to care what programming language or option parsing library the developer chose. argparse, Click, Go's flag/X11-style, and many other similar libraries break conventions that are ingrained in half a century's collective muscle memory.

But with a layer in the middle, it sounds like you can eat your cake and have it too.

[0] https://github.com/chriskiehl/Gooey/blob/be4b11b8f27f500e732...

It's only super old because you abandoned it (and I don't mean to be judgemental, it is what it is). Worse yet, no viable alternative has shown up to replace it nor either of its forks gained traction.

Argparse is good for simple stuff but there are many Click based CLI's and a lot of popular CLI libraries build on top of Click. There are also other Python CLI tools that aren't built on argparse or Click, though I will say that these two are probably the most popular ones.

Is this confirmed to work with Click? I only see references to argparse. I would go so far to say, if the answer is no, that "almost any" is a flat out lie, and a much more accurate title would be "Turn almost any argparse-based Python command line program into a full GUI application".

Also, the last substantial commit was over two years ago. This isn't itself a bad thing, but given the open issue count does not really signal confidence in the project.

Otherwise it is a cool project. I would like to see more of this - it's one of those neat force multipliers, as referenced in the README, that some enterprising person could implement as a CLI and then share their automation for the rest of the nontechnical office in an easy way. Kind of like how Access did the same thing for DB's. Like Access, you would butt up against limitations once you started to introduce some level of size or complexity, but it could be "good enough" for a lot of small office use cases.

Gooey: Turn almost any Python command line program into a GUI application - https://news.ycombinator.com/item?id=27490291 - June 2021 (115 comments)

Gooey: Turn command line programs into GUI applications - https://news.ycombinator.com/item?id=8218785 - Aug 2014 (74 comments)

I'd love to see programs communicate through a typed JSON/proto format that shed enough details to make this more independent, and get useful shell command structuring/completion or full blown GUIs from simply introspecting the expected input and output types.

Today it seems that the best you can get is still made out of carefully placed straws as programs need to export completion files to many shells, there's vastly different styles for flags across programs and parsing libraries, and obviously, there's no GUIs around.

You should try PowerShell. It's basically Microsoft's .NET ecosystem molded into an interactive command line. I'm not entirely sure if PoweShell can make full use of the static types that build up its core, but its ability to exchange objects in the command line is almost unmatched.

On Linux you can use `jc` (https://github.com/kellyjonbrazil/jc) combined with `jq` (https://jqlang.github.io/jq/) to glue together command lines, but that's still two extra steps you need to deal with compared to PS's built-in capabilities.

I didn't know of `jc`, but it seems that using nushell (https://github.com/nushell/nushell) gets you a better experience.

nushell does look interesting, though the lack of a .deb repository does put it pretty low on my to-do list.

It’s just that the tooling around it isn’t as easily exposed and they aren’t tailored for on-demand launch via command line. If the shell treated such as a more first class citizen, good results may come out.

Another big problem is portability, if you designed your app with sdbus, it’s not going to work on a non systemd distro, even less on Windows. What’s needed is a standardized abstraction layer on top.

A bit tangential to current discussion, but i came across CUDATEXT editor a few months ago here which provides a single file python API to let me use arbitrary GUI elements like MENU, INPUTS etc which editor is itself using. I currently generate my blog from editor itself with configuration done through these simple GUI elements.

"Textual: lean application framework for Python. Build sophisticated user interfaces with a simple Python API. Run your apps in the terminal and a web browser." [1]

[1]: https://github.com/textualize/textual/

[1] https://juftin.com/camply/

Very cool idea but it never worked out (to my knowledge).

IMO, the trouble is that it couples vertical concerns (presentation, domain, infrastructure). It's fine as long as the domain model has trivial presentational and database representations.

However, if you want to make a complex interface with many convenience features, you'll have to let those requirements bleed into your domain layer; and if want to create complex domain models, it's impractical to enforce invariants at the language level (since anything with a reference to a Model can do arbitrary things to it).

https://github.com/blooop/bencher/tree/main

I don't think it would be a massive time saver however what I usually do now is find some previous script that had similar arguments and copy them, and then copy-paste-edit to add new arguments.

The other advantage is you could enter the arguments agnostically and export as whatever language you're working in.

Not quite what you asked for, but close: type example invocations to generate the CLI, and just pull the arguments from a dictionary at runtime.

Oh, apparently, A/UX had commando as well. If you double-clicked a terminal command from the Finder, it would pop up the commando box to choose your CLI options, then run it in a shell window. Today, running a terminal command from Finder just runs it without any arguments in a shell window.

https://cohost.org/boredzo/post/804893-i-still-want-a-moder

http://toastytech.com/guis/aux3.html

[0] https://github.com/livetheoogway/python-uime

Would love to package this around a bisect script I use to debug issues for my game engine. Giving it a GUI would make it possible to share it with users such that they too can help bisect problems.

[1]: https://github.com/MichalGniadek/klask

[2]: https://github.com/grantshandy/claui

someone is surely doing a smalltalkish metaclass trick to turn any object into a local tty or http or rest or else interfaced thing

Now we'd like the converse program: one that transforms any GUI application into a cmdline tool or wraps it. ;-)

In spirit, Gooey reminds me of one of my favorite low-code tools for technically savvy individuals to put a web frontend in front of arbitrary CLI programs:

Python Script Server

https://github.com/bugy/script-server

Launching it only on demand is an interesting idea, and I totally get your sentiment on bloat. I was a 90s teen, 32MB of ram was enough for just about everything at the time, while today that's "embedded" territory, haha. Still, these days my web browser is generally already open.

Anyhow, maybe my writing could have been more clear. I was thinking of it differently, running the app as a persistent webserver. Then I could access the things from anywhere. "Accessible from any web browser" is one of the primary properties I like about the Python Script Server (mentioned/linked in my first post).

Just imagine if someone somehow figured out how to make a Gooey equivalent for Go or Rust. If done well, it could become very popular. Especially considering the difficulty of creating UIs in those languages! Much more challenging than Python.

(notably Tcl/Tk deals with remote X over ssh nicely and far too many things these days don't so much)

Try: https://amiaopensource.github.io/ffmprovisr/

for a 'better' ffmpeg CLI documentation, your mileage may vary, it's task and example focused.

Try: https://github.com/topics/ffmpeg-gui

for 66 variations on a GUI for ffmpeg of which I have no comment, I'm an old school CLI user through and through.

I'm very happy to see an example of it already done in Python!

be great if you could build/package python code easily to run on native OS's without having the user install python, etc first.

>Feels good man

And deprecated for going on 11 major versions of Python.

Interestingly, there is a gooey-inspired GUI generator for Click-based programs: https://github.com/szsdk/quick