As the person who originally invented (or co-invented? Not quite sure anymore) that trick of using a binary inside the App bundle, and the horrible scripts to create it: there’s a couple of things worth noting:
- There are now perfectly sane ways to build bundles (whether Framework or App bundles) using the Apple command line tools. So if there’s still any of the old cruft around it should go out the window. - I _think_ that the restriction that a GUI program must be in an App bundle no longer holds, or at least there are ways around it. There are all sorts of programs installed with brew that present a GUI without being in an app bundle. I’m looking at realsense-viewer right now, as an example, and it’s a normal executable in /usr/local/Cellar/librealsense/2.22.0/bin/realsense-viewer with a symlink in /usr/local/bin. - But: this still doesn’t bring the OSX builds in line with “normal” unix builds. To do that Python would have to do away with Frameworks and go move to a normal dylib/so/dll structure. That would seem very unwise, especially nowadays as Apple is moving more and more towards having everything that you want to install be signed and notarized and whatnot. I wouldn’t be surprised at all if some time soon “free dylibs”, i.e. dylibs outside of an app bundle or framework bundle, become impossible unless you build them yourself from source. Jack > On 09-Mar-2020, at 17: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 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 -- Jack Jansen, <jack.jan...@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
