In article <calgmxejczecmap_enqhom-9rma9ubx-z6uytruum3arbdgw...@mail.gmail.com>, Chris Barker <chris.bar...@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, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
