On 8 Jan 2021, at 20:38, Chris Barker via Python-Dev <python-dev@python.org> wrote:

Sorry if I'm out of the loop here, but with Apple's new chip coming out, we need new a build configuration (which I think has already been started, if not done).

Perhaps we could take this opportunity to better modularize / unify the build setup?

As it was last I checked, you really had only two options:

1) Ignore anything mac specific, and get a "unix" build.

2) Get a full "Framework" build, optionally with Universal support.

It would be nice to keep the Framework structure independent of the Mac-specific features, if possible.

In particular, I'd love to get be able to get the "pythonw" executable wrapper in an otherwise standard unix build [*].

That’s a feature of the framework build. The unix build is exactly the same as a unix build on other platform.  Adding the same feature to the unix build should be possible, but would complicate the build.  I have no interest to work on this, but would be willing to review PRs, as long as those aim for feature parity with the framework build. That is, both pythonw(1) and python(1) should redirect through an embedded app bundle.


It would also be nice if it were possible to get universal binaries in a "unix style" build.

Let me sneak away in Guido’s time machine for a while.  


Done, just configure “—enable-universalsdk —with-universal-archs=universal2” without specifying a framework build.


(option 3 would be to simply abandon the Framework Build altogether -- it's still not clear to me what this really buys mac users)

In some ways this is historic, but frameworks are still the way to build a self-contained library on macOS. A major thing this buys us is having side-by-side installs of Python. 


Any chance of this happening? I'm afraid I know nothing of autoconf, so can't be much help, but I'd be willing to help out with testing, or documenting, or anything else that I have the skills to do.

That’s not really something I intend to work on.  

Something I would like to work on, but don’t have enough free time for, is an alternative installation with an application bundle on the top level instead of a framework.  Installation would then entail dropping “Python X.Y.app” into your application folder, and uninstallation would be to drop the same bundle into the bin.   This might also make it possible to distribute Python through the Mac App Store, although I haven’t checked recently if sandboxing requirements have been relaxed enough to make that worthwhile. 
 

Thanks,

-Chris

[*] The pythonw issue has been a thorn in the side of conda for years. conda uses a standard unix build on the Mac, for consistency with other unix systems. But there is no configuration set up to build the pythonw wrapper outside of a "Framework" build. So instead, conda has creates its own "pythonw" wrapper -- but that is a bash script that re-directs to a different executable. This works fine on the command line (or #! line), but it does not work with setuptools' entry_points. And the setuptools community hasn't shown any interest in hacking around it. Anyway, few enough people develop Desktop apps (particularly with conda) so this has lingered, but it would be nice to fix.

Just don’t use conda ;-).  To be blunt, doing this properly is trivial.

Ronald


Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/