All,
(mostly Ned and Ronald...)
TL:DR:
Are there any plans to update the build scripts for the python.org
python(s)? It would be really nice to get the mac builds more inline with
the rest of the Unix world.
Longer version:
Over on Conda-forge, we've been struggling with the whole Python.app Bundle
thing:
https://github.com/conda-forge/python.app-feedstock/issues/8
which resulted in:
https://github.com/conda-forge/python.app-feedstock/pulls
Which looks like it's going to solve the "problem at hand".
(NOTE: what that PR does is put a symlink in the app bundle to the main
executable. So pythonw is a bash script that redirects to the symlink in a
bundle which is linked to the regular python executable. I'm amazed that it
works, but it seems to)
But really, it seem that it would be better if in the conda world we "did
this right", which is to say build a python binary that re-directs to a
version inside a bundle to make the OS happy, like is done with the
python.org Framework builds.
There are a number of issues and discussion out there, semi-summaries here:
https://github.com/conda-forge/python-feedstock/issues/23
But a summary is:
The Mac requires that a GUI app executable be "inside" nd application
bundle to access the GUI. This means that a regular old python interpreter
can not be used to run a GUI app (Tk, wxPython, QT, etc.).
This was "solved" many years ago in the python.org "Framework" builds of
Python, by writing a small wrapper around the pythonexe that re-directs
itself to one inside an app bundle. This acts just like a regular command
line executalbe, and thus "python" and "pythonw" can be links to the same
thing.
However, when Anaconda (and now conda-forge) started, they did not use a
Framework build, preferring to keep python more standardized and *nix-y. So
they solved the problem by making a "pythonw" command that is a bash script
that re-directs itself to a copy of the python executable inside an
application bundle. This is delivered as a "python.app" package via conda.
However: while this hack works fine from the command line, it does not work
with setuptools entry points, and other ways of running the app. This has
been a thorn in the side of the (admittedly small) group of folks using
both conda and developing OS-X Desktop apps. And the setuptools folks seem
to have no interest whatsoever in updating setuptools to accommodate
pythonw.
So what I"d like to see happen is for conda-forge to build its python on
OS-X with the little wrapper so that it can be used in place of this whole
python.app hack. I think there are not technical reasons that can't be
done. But the current configure scripts for python.org don't provide that
option, and there has been no one with both an interest in this, the
autotools skills, and the time to make it happen.
I just looked again at the building instructions for the Pyhton.org builds,
and they seem to be pretty old. The Mac has moved on and it seems it would
b good to updated those build options anyway: Do we need 32 bit anymore? Do
we need Universal builds anymore? Should we abandon the Framework build
option altogether?
My proposal: Add a build option that builds Intel, 64bit, fairly recent
SDK, and the pythonw hack, into an otherwise "standard" unix-like build.
Then that could become the default OS-X build in the future, exactly when
TBD.
The problem is that I *really* don't have the autoconf skills to do that!
But I'm hoping with some prodding and show of support, someone with take it
on :-)
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
