I will describe one possible way to achieve this using the followingfeatures:We want to create a package layout that can support a CLI interface, animportable library, and a GUI all while sharing as much code aspossible.Although text and graphical interfaces are very different we can providea consistent API with careful consideration. This way users can easilyuse our library or either interface without starting all over again.First we will layout a single-file CLI script using argparse similar tothe Unix ``wc`` tool that takes a text file and outputs the followinginformation:We'll discuss the ``__name__ == __main__`` Python idiom, separating theargument parsing from the main function, and why keeping as little aspossible in ``__main__`` is better for reusability.There are several pros and cons to providing others with a single-filescript. It's easy to develop and simple to read, but it requires anyuser to have the correct version of Python installed. It's alsodifficult for other developers to reuse the code in their own projectsor deploy to PyPI.Next we'll take our single-file script and expand it into a basic Pythonpackage using a main folder, **init**.py, and a cli.py script to exposethe same CLI as before.We'll discuss how to restructure the main and parsing functions fromstep 1 into an public API defined by the **init**.py that exposes thesame CLI functionality as a library.We won't dive into setup.py at all, but there will be links and a briefdescription on the various tools to layout a package such ascookiecutter and setup.py.The `Gooey `__ project can easilyexpose a CLI as GUI with a few decorators. We'll discuss briefly how touse Gooey and some of the extra functionality it provides to create moreadvanced GUIs.We'll also give a simple mental model for how it maps argparse argumenttypes to GUI widgets.Until step 3 all we required of users was a working Python 3installation. However, adding Gooey requires users to have a workingPython installer, the Gooey library, and wxPython. Typically GUIs aremeant for higher-level users so asking them to install all of this tobenefit from our little app is too much.Instead we'll see how we run PyInstaller on our entry script to packageup all our dependencies **including** Python itself into a simpleexecutable. We'll briefly discuss the build and dist output folders fromPyInstaller along with the ability to use it to package all sorts ofcomplicated Python applications using Qt, Numpy, etc.End-users in management don't even have to know we used Python!
I am looking for editors/curators to help with branches of the tree. Please send me an email if you are interested.