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

[Barry Scott]

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

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

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

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: 

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

[Christopher Barker]

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