[Pythonmac-SIG] What does it take to run a GUI app?

[Ned Deily]

In article 
<CALGmxEJCzECMaP_enQHOm-9Rma9ubX-Z6UytRUum3arbdgWzeQ at mail.gmail.com>,
 Chris Barker <chris.barker at noaa.gov> wrote:
> Over on the list for the Anaconda distribution, we've run into a limitation
> in our understanding of the whole app bundle, etc business.
> 
> The problem is thus:
> 
> Anaconda is currently built with the old python / pythonw dichotomy.

On vanilla OS X python builds, there is no difference between python and 
pythonw; that's been the case going back many years.  pythonw* files 
are/were just symlinks to the correspoing python* files.  In fact, as of 
3.4, we no longer make the pythonw* symlinks.

> python is a standard unix-style executable -- great for command line apps,
> web servers, what have you. But you get the dreaded:
> 
> """
> This program needs access to the screen.
> Please run with a Framework build of python, and only when you are
> logged in on the main display of your Mac.
> """
> 
> when you try to run a GUI app (this error message from wxPython)
> 
> pythonw, on the other hand, is a shell script that re-directs to a python
> that is inside a hand-built application bundle:
> 
> #!/bin/bash
> export
> PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python
> /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py
> thon
> $@

This is something supplied by Anaconda?

> This all sort-of works. But it's a pain, because you may not know when you
> start up an app, whether it needs to access the Window manger (like
> iPython, for instance). And now I need to put "pythonw" in my #! lines,
> which may fail on other *nix systems, and...
> 
> One thought is to simply have "python" be the same shell script as
> "pythonw" but there is concern that having it be a re-directing shell
> script may cause problems for some use cases.
> 
> I know that this has been solved for years in the python.org installer. So
> how is that done?

A framework build, like used in the python.org installer, creates a 
Python.app app bundle within the framework:

/Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app

and the real Python executable is located there, in 
./Contents/MacOS/Python like a standard OS X app.  The tricky part is 
that a bootstrap executable, built from the somewhat confusingly named 
pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c), 
is what is actually installed into the framework bin directory and 
symlinked to from /usr/local/bin/ or wherever.  The bootstrap 
executable's job is to essentially transparently launch Python.app from 
the command line.  That is, when you type:

/usr/local/bin/pythonx.x 
or
/Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y

you are first executing the bootstrap executable and it then spawns or 
execs the real interpreter executable under Python.app so that Python 
runs as a app that can be a gui process.

Now, these days, most of the time you probably don't need to be a gui 
process, especially since we no longer support the obsolete deprecated 
Mac Carbon-based API wrapper functions in the standard library.  And if 
you are building you own gui app, presumably you can use py2app to 
produce your app as its own app bundle.

I'm not familiar with wxPython at all but, if it doesn't already, it 
might be able to take the approach Tcl/Tk does on OS X.  Tk seems to do 
some tricks to make itself a gui process and it also has an embedded 
Wish.app at least when Tk is built as a framework.  But I haven't looked 
closely at it.  The relevant code in the the Tk file 
macosx/tkMacOSXInit.c.

> Anaconda doesn't seem to want to make their python a proper framework build
> -- don't know why not -- would there be any downside? But is it possible to
> build the python executable so it can access the GUI system without
> structuring their whole python install?

One issue might be that the current framework builds are meant to be 
installed at a fixed path, by default /Library/Frameworks.  You can 
change that at build time but we don't support changing it at install or 
run time.

Without knowing more, I'd look to solving the issue in wx rather than 
Python since it might affect other users as well.  The Python framework 
GUI stuff is quite old and hasn't really been closely examined in a long 
time.  There *might* be better ways to do it today.

-- 
 Ned Deily,
 nad at acm.org