On Tue, Jan 30, 2018 at 6:50 PM, Ray Donnelly <mingw.android@gmail.com> wrote:

While we're making such macOS-build requests, any chance of building a static interpreter too? We've been doing that on the Anaconda Distribution since the 5.0 release in September and it seems to be working well.

PyPy is also currently eyeing doing their macOS builds better: https://bitbucket.org/pypy/pypy/issues/2734/establish-a-build-and-release-pi... What do the Anaconda static builds get built on? -- Joni Orponen

On Tue, Jan 30, 2018 at 7:08 PM, Matt Billenstein <matt@vazor.com> wrote:

OSX is in a sad state linking to system libs on the later releases -- maybe 10.11 and on, not sure of the exact release -- they stopped shipping the headers for things like ssl and ffi since they don't want 3rd parties linking to deprecated versions of those libraries versus, in the case of ssl, their newer security framework. Recommendation is to bundle what you need if you're not using the framework -- something to think about.

There are also some practical issues with trying to distribute software using some deprecated Cocoa APIs or weak linked syscalls. The pythonmac-sig thead I linked to earlier has pointers to how to flare those up if one ever needs to distribute Python to a specific macOS version target range while compiling on a newer macOS. It would be nice to do more things the Apple way, including porting to modern runtime feature availability check cascades of the Cocoa APIs and using the Apple provided system Frameworks. This seems like a rather major workload and should be targeting 3.8. I'm willing to participate in that effort. The availability of syscalls across targets when cross-compiling for an older target is a more generic build system problem and I'm not sure if Python should do anything other than just document it being a thing. I'm personally fine patching pyconfig.h after running the configure script for this special case. As suggested on pythonmac-sig, I'd like to see 10.11 get chosen as the macOS to build on as it provides a decent balance between hardware compatibility and being new(er). -- Joni Orponen

On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:

And maybe we could even get rid of the "Framework" builds......

...

Please do not. These make life easier for doing things the Apple way for signed sandboxed applications.

Thanks — good to hear there is a good reason for them. I’ve always thought that Frameworks were designed with other use-casss, and didn’t really help with Python.

For the record, are you re-distributing the python.org builds, or re-building yourself?

We are re-building ourselves. Seems we've cooked up something not too unsimilar to what Anaconda is doing, but less generic and covering less corner cases. -- Joni Orponen

On Thu, Feb 1, 2018 at 12:18 AM, Chris Barker <chris.barker@noaa.gov> wrote:

On Wed, Jan 31, 2018 at 3:13 AM, Joni Orponen <j.orponen@4teamwork.ch> wrote:

...

On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:

...

And maybe we could even get rid of the "Framework" builds......

...

Please do not. These make life easier for doing things the Apple way for signed sandboxed applications.

For the record, are you re-distributing the python.org builds, or re-building yourself?

We are re-building ourselves.

Then it makes no difference to you if the pyton.org binaries are Framework builds... though maybe you want the configure target available.

And if the official distribution distributes a Framework, the configure target and build for that are also actually maintained, which will keep them likelier usable. Would we not be doing a couple of very specific things, we'd be able to use the distributed Framework as well. It is not unconceivable we could use it as-is in the future or for other projects. -- Joni Orponen