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

[Barry Scott]

> On 9 Mar 2020, at 16: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.
> 
> 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 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/20200309/8e8fe3c9/attachment-0001.html>