[Pythonmac-SIG] Building plans .....

Wed Mar 11 10:58:31 EDT 2020

> On 9 Mar 2020, at 17:53, Christopher Barker <pythonchb at 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.

I’m not very active at the moment, but…  framework builds and in particular the embedded Python.app are necessary to be able to use GUI libraries on macOS in scripts. The alternative is that users always use py2app/pyinstaller/… to build an .app bundle themselves.  

A side-effect of having a Python.framework is that this makes integration with Xcode slightly easier, but that’s a secondary concern. We primarily used a framework because that was the modern platform way of packaging libraries with supporting files (instead of sprinkling everything into /usr/local). 

> 
> 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 <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)

So you are not using a regular installation… In a regular framework build $prefix/bin/python and …/pythonw is a small executable that launches the python executable in the embedded Python.app (which is the executable that is $prefix/bin/python in unix installs). 
> 
> 
> 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.).
> 
> 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. 

What’s wrong with using a framework install? That makes is trivial to have side by side installs of a number of Python versions, and makes it easy to remove one of them (although that’s less of a concern from Conda because the tool manages installation and deinstallation for the user).

It should be easy enough to use the pythonw “hack” from the Python.framework with a Unix install, the hard part is tweaking the build process (in particular the Makefile).

BTW. I’d prefer to not add yet another build configuration on macOS, having both Unix and Framework installs is confusing enough. If the pythonw “hack” is considered useful for Unix installs it should be enabled unconditionally in 3.9. 

> 
> Then that could become the default OS-X build in the future, exactly when TBD.

BTW. Looking further toward the future I’d love to spent time on creating a “Python.app” that replaces the current framework installers, with some effort that could remove the need to run installers at all and might even make it possible to distribute Python through the macOS App Store.

> 
> 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 :-)

I won’t, finding time to work on Python is hard enough and I’d rather not spent that time on fighting the build system ;-).

Ronald

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20200311/75235ea5/attachment.html>