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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG