
Using Gooey as a Universal Front End for Any Language or CLI Application - goostavos
https://chriskiehl.com/article/gooey-as-a-universal-frontend
======
icegreentea2
I've been using this to wrap CLIs for internal tooling at my company [it's
also my first accepted contribution to a FOSS project =D ]. Works well, but
subject to the usual Python packaging issues. If I needed to wrap a CLI with a
GUI for my users, that probably means I don't want to walk them through
installing Python and dependencies either. That means using something like
PyInstaller, which I can report plays well with Gooey.

~~~
vxNsr
Isn't the idea here that you're getting a binary at the end of it that doesn't
require any of the dependencies? or do you need the full environment?

~~~
icegreentea2
I don't think I'm understanding your question, and maybe I haven't laid down
the situation fully.

My company is a Windows shop, and nearly everyone who isn't a developer (so
nearly my entire internal customer base) does not have Python installed.

I want to be able to send over single file executables that have everything
they need. I don't want to have to think about using pip, or distributing
wheels, or making sure they have internet access, or if they have admin or
not. And as internal tools, I can afford to deal with relatively large file
sizes.

For example, I have a lot of tools that need numpy and scipy to accomplish
their goals.

That all said, Gooey + PyInstaller typically does a good job at solving my
problems.

~~~
triangleman
I think what he was asking was, could there be some way of packaging a .exe
with a full python environment and all dependencies built in (and so zero
install basically)?

Edit: after reading the docs for pyinstaller, it seems that this is exactly
what it does. vxNsr was either confused about what gooey does, or, like me,
got confused by the name "pyinstaller" and assumed it was a tool to help you
install a python environment on Windows.

~~~
mickotron
Yes, you can compile the python script/program to a windows exe file. It is
quite large cause it has to also include all dependencies. However it does
work. Can't remember what I used but a quick Google search would bring it up.

~~~
triangleman
I believe it's called pyinstaller

------
jlarocco
Never heard of this, but I once wrote a Perl script (it was a long time ago
;-) that created Perl/Tk UIs around CLI tools by parsing the output from "$CMD
--help" or "man $CMD".

It never worked perfect, but was "good enough" for the few simple things I
needed it for.

------
yourapostasy
This is neat to see on Linux, it reminds me of Platypus on OS X [1], which in
turn drew spiritual inspiration (that is, I don't know if the author of
Platypus knew about these) from CLImax [2] and even earlier, Macintosh
Programmer's Workshop [3] [4]. I don't know where MPW got the idea from, that
just happens to be where I first encountered it. Thanks to user
classichasclass in this thread for reminding me that the feature was called
Commando in MPW. I'm curious if it originated with MPW.

[1] [https://sveinbjorn.org/platypus](https://sveinbjorn.org/platypus)

[2]
[http://www.storiesofapple.net/climax.html](http://www.storiesofapple.net/climax.html)

[3]
[http://www.storiesofapple.net/tag/mpw](http://www.storiesofapple.net/tag/mpw)

[4] [https://www.semanticscholar.org/paper/The-Macintosh-
Programm...](https://www.semanticscholar.org/paper/The-Macintosh-
Programmer's-Workshop-Meyers-Parrish/846e90c6a250f83674b31718eecf11ed2452f498)

------
carapace
I'm not a big fan of GUI in general but, ooo, this is nice.

Combine with python-fire for great fun, eh?

> Python Fire is a library for automatically generating command line
> interfaces (CLIs) from absolutely any Python object.

[https://github.com/google/python-fire](https://github.com/google/python-fire)

------
classichasclass
It's Commando for a new generation.

[http://preserve.mactech.com/articles/mactech/Vol.06/06.07/Co...](http://preserve.mactech.com/articles/mactech/Vol.06/06.07/Commando/index.html)

~~~
klodolph
I was looking to see if Commando would get mentioned. One of the really nice
things about Commando was that it would synthesize the command line for you
and not just run the command, and it was integrated with the MPW editor. So
you could go through the GUI for a program, press a button, and the command-
line invocation is pasted into the script you’re editing.

MPW was ahead of its time in a lot of ways, unfortunately behind its time in a
couple ways (notably, pipes didn’t work the way they did on Unix—I think there
was something like temporary files involved).

------
qwerty456127
Looks extremely cool. I used to enjoyed developing GUIs with WinForms but now
as this technology is obsolete and no relevant replacement is available (both
web-UIs and Qt are too complex and WPF is Windows-only) this seems extremely
attractive. Can it also display progress and output data (a matplotlib plot
and/or a data table)?

~~~
JCoder58
If you like WinForms, take a look at Eto
([https://github.com/picoe/Eto](https://github.com/picoe/Eto))

"This framework can be used to build applications that run across multiple
platforms using their native toolkit, with an easy to use API. This will make
your applications look and work as a native application on all platforms,
using a single UI codebase."

~~~
qwerty456127
Thank you, I'll take a look, but it hardly is a real replacement. Honestly, I
liked WinForms because it had a visual designer where I could just paint the
UI with a mouse, click a button and code what's going to happen when it's
clicked. Nevertheless anything like WinForms probably is easier than web-based
UIs, even if it lacks a visual designer. However, one should probably prefer
Avalonia (a cross-platform WPF-like .Net UI toolkit) if going this way.

------
uluyol
Looks like a variant of dialog[1] and its many X11/gtk/qt/etc forms.

What was nice about dialog was that it was called to collect input by the
application, so the application could ask (from a ui) some input, then later
on ask for or display something else. Does Gooey support the same sort of use
case?

[1]
[https://www.linuxjournal.com/article/2807](https://www.linuxjournal.com/article/2807)

------
andrewstuart
Things that might be generally useful for cli programs:

 __creating GUI interfaces for them (what this does)

 __enhancing CLI interface to include autocomplete including help with options
and arguments

 __wrapping CLI commands to turn them into APIs /make them programmable

~~~
tomc1985
> wrapping CLI commands to turn them into APIs/make them programmable

CLI apps are already very programmable. How would you API-ify them even more?

    
    
      system('yourapp --option1 --option2=something')

~~~
spullara
Input and output types would be a good start.

~~~
NullPrefix
\--output=json

~~~
spullara
That isn't a type, but I like the direction you're going.

------
etaioinshrdlu
Cool! I'm wondering if there's any possible way to automatically generate
GUI's for command line applications. Including all the supported arguments.

Some type of crawler would interact with a program, parse its --help output,
man page, or any other info available, to enumerate all possible options and
their formatting.

It sounds like a really messy program considering how inconsistent CLI's are.

Anyways, a GUI could help massively with discoverability.

Such a tool could help bridge the gap a little between GUI and CLI.

~~~
TylerE
I can’t see how that would handle any of the hard bits (like dependencies
between arguments, mutual exclusion)...

~~~
gojomo
To the extent the command-line program returns proper exit codes, or gives
other hints via its output/side-effects as to whether it did anything useful,
I could see it working up-to-a-point.

Discovering exclusive options, or options that must be specified together,
sound like exactly the sorts of things it _could_ deduce, when every
invocation with/without certain pairs of options fails.

Perhaps wrapper-utilities like 'Gooey' or some sort of automated-probing could
encourage a greater formalization for specifying de-facto command-line APIs.
Then, command-line programs might want to offer not just the human-
interpretable help texts and docs, but more rigorous usage-specs that _could_
drive automatic wrappers.

~~~
TylerE
Probing at options sounds dangerous. There is no guarantee at all that
attempted invocations won't change state.

~~~
sunebeck
I wouldn't wanna let it probe 'rm' :D

Perhaps the probing could happen in a VM / container image which would reset
after each invocation.

------
dmix
Makes sense, basically turns any CLI program into an API with the simple
translation interface being the unix shell textual interface via simple JSON
files which contain the commands.

------
m_ke
I'd love to see a new python type annotation based tool that could decorate a
function and let you expose it as a CLI, a GUI or a REST/GraphQL API (maybe
even an html form).

pretty much a combination of Gooey, click and FastAPI

~~~
melq
You might be interested in this, though it doesn't cover GUI stuff afaik:

[https://github.com/hugapi/hug](https://github.com/hugapi/hug)

------
xfer
I have been using yad based on gtk ([https://sourceforge.net/projects/yad-
dialog/](https://sourceforge.net/projects/yad-dialog/)) for some shell scripts
and wrappers to external tools.

------
nickserv
It's using the wxWidgets library for the heavy lifting, so should be fast and
have native feel on multiple platforms.

Very cool, going to try this out for some of our internal toolkits. Easier
than reading the help files for newbies, still has CLI for automating.

------
ageofwant
This is nice. But I have long since abandoned argparse in favour of click. And
most 'serious' cli apps use click in my experience. Having click support would
make this very interesting for many of my work projects.

------
gbog
Gooey is nice, it could help in a wish I have had since foreveR and is the
contrapositive: a way to convert any action I do on my Xubuntu UI into a
command line.

Example: I pop the display config, hide the laptop screen, apply and confirm,
and whish there was a "log" somewhere with a one line command I can use next
time to redo the same thing.

In a way Gooey, if used a lot to make GUI apps, could help fullfilling this
whish: I did not use it yet but I hope it displays somewhere the command line
it generated from the GUI?

~~~
arnsholt
For your concrete example of display configuration, I think `xrandr` is the
command you're looking for.

------
blt
It seems like almost a drop-in replacement for the widely used `argparse`
standard library. Strange that there is no mention of this.

~~~
goostavos
That's because it IS a drop-in replacement for Argparse

Gooey began its life as a monkey-patch of argparse. GooeyParser came along
later to extend the limited argparse API with additional options that made
specifying more complex GUIs possible.

I opted to leave that detail out of this one as I was trying to focus on the
larger general capabilities, rather than the Python specific implementation
details.

~~~
blt
I would include it, at least as a footnote/sidebar! It will be a huge selling
point for python projects that already use argparse, and there are a lot.

~~~
goostavos
Good idea. I'll do a quick update!

------
hasahmed
Is there a repository of Gooeys people have made?

------
fit2rule
I've always thought that a natural 'friend library' for libargs or libopts
could be produced which parses the args and creates a dynamic gui from it ..
but now I look at this and wonder, why hasn't someone done this already? It
seems like obvious low-hanging fruit ..

------
thanatropism
Something like this for the web would be awesome. Maybe closely tied with
something like FastAPI.

~~~
icegreentea2
I ran into [https://github.com/wooey/Wooey](https://github.com/wooey/Wooey)
when I first ran into Gooey (years ago) and had the same thought.

------
shashankp
From the link:

gooey_options={ # NEW! 'validator': { 'test': 'user_input.isdigit()',
'message': 'Please enter a number' } })

'test': 'user_input.isdigit()',

'user_input.isdigit()'

'o'

------
Uplink
Gooey could use a GUI that generates the Gooey config at the press of a
button.

------
logicprog
I don't want to be a downer, and this is definitely a very cool product
indeed, but doesn't converting command line tools into GUI apps sort of rob
them of a lot of their usefulness? The reason I prefer to use the CLI (besides
ergonomic reasons and having a horrific $5 mouse) is that I have a consistent
interface which can be manipulated (pipes, redirection) and also are
scriptable and repeatable. These GUI versions dont have any of that?

~~~
lsh
No CLI app is being robbed of anything, this is a layer over the top.

GUIs are very valuable because they can do things CLIs cannot, like show you
at a glance what operations are available, promote the standard usecase of the
CLI etc. Stuff that takes a bit of reading and clever typing with a CLI.

This tool allows you to quickly write a highly specific GUI that is using CLI
app in the background.

~~~
thethirdone
> like show you at a glance what operations are available, promote the
> standard usecase of the CLI etc.

I definitely agree with this. I think getting people up to speed on how to use
a CLI tool would be a great use case for this.

I would probably use more cli tools if there was a clear GUI introduction that
shows how the options map to the commands.

------
tyingq
Any screenshots of what it does with stderr?

~~~
goostavos
Sure. Check this out:
[https://imgur.com/a/2TNi8SZ](https://imgur.com/a/2TNi8SZ)

It displays on the main screen and pops a modal.

Edit: pops a modal if the return code is non-zero, that is. If its just piping
stuff over stderr as part of its normal run, it will be logged to the screen
like normal stdout.

~~~
tyingq
Thanks...seems like a reasonable approach.

------
luord
Sounds exactly like the tool for spinning out quick mockups I was in need of.

------
fouc
Finally, now people can make a GUI for git if they need one.

~~~
proc0
Yes, this is exactly what i'll use it for.

------
abledon
Rebrand with better name and it has a chance for adoption. As dumb as it
sounds , if you start pushing tech with that spelling and name to business
types they won’t like it

~~~
daRealDodo
I don't think the goal of an open-source project is to push it to business.

~~~
abledon
well if you want wide adoption of your product (OSS or not), a good marketing
strategy can't hurt -- including a good product name

