> On 9 Mar 2020, at 16:53, Christopher Barker <python...@gmail.com> wrote: > > All, > > (mostly Ned and Ronald...) > > TL:DR: > > Are there any plans to update the build scripts for the python.org > <http://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:
Just curious. I do not seem to have a Python.app on my macOS. What project makes the python.app? Is it a Conda built .app? > > https://github.com/conda-forge/python.app-feedstock/issues/8 > <https://github.com/conda-forge/python.app-feedstock/issues/8> > > which resulted in: > > https://github.com/conda-forge/python.app-feedstock/pulls > <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 <http://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 > <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.). I can use the /usr/local/bin/python3.7 to run Qt code and the windows appear. I do not see any .app running to make this work. I do this all the time to debug PyQt code so that I can print to stdout. I do not use the pythonw version and do not recall hitting the problem form the command line. > > This was "solved" many years ago in the python.org <http://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 <http://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 :-) Barry > > -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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
