search

indygreg / python-build-standalone

Produce redistributable builds of Python
BSD 3-Clause "New" or "Revised" License
1.71k stars 107 forks source link

Provide a native aarch64-darwin build of 3.8 #118

Closed alexeagle closed 2 years ago

alexeagle commented 2 years ago

Hey, thanks so much for providing this resource!

Now that Bazel rules_python includes these standalone interpreters, we're wiring that up and found that lots of users are still on 3.8 which does support Mac M1 architecture. But there's no release here.

Back in https://github.com/indygreg/python-build-standalone/issues/64#issuecomment-782776365 you discussed this a bit, but that only seemed to reference Python 3.9.

alexeagle commented 2 years ago

@mattem has a patch that allows an M1 build for 3.8.12

indygreg commented 2 years ago

The CPython 3.8 backport to build on M1s came months after initial M1 support landed in 3.9/3.10. When I last looked at things a few months ago, my perception was very few popular packages on PyPI were offering 3.8 binary wheels for aarch64 when they offered them for 3.9/3.10. This gave the perception that the Python community effectively requires 3.9 if running on M1.

While I'm not opposed to the idea of providing 3.8 aarch64 macOS builds, I'm also not super thrilled about supporting it either. (In my mind Python 3.8 is already outdated since the transition from 3.8 to 3.9 is ~effortless.)

Are you sure there is a market for 3.8 on M1?

alexeagle commented 2 years ago

Yes, quite sure there's a market :)

We're working with large companies with massive enterprise monorepos, and the 3.8 to 3.9 upgrade is quite a lot of work. We'd want to use a pre-built interpreter sooner than that work will get prioritized. Apple is no longer scheduling new shipments of x86 machines, so these enterprises are going to be stuck with 3.8 and developers forced onto M1 arch.

indygreg commented 2 years ago

I just pushed a commit to main adding the 3.8 M1 compatible builds. Since there haven't been any meaningful commits since the last tag, I'll likely manually edit the timestamps of the builds and publish the artifacts to the most recent release.

alexeagle commented 2 years ago

That's amazing, thank you!!

indygreg commented 2 years ago

I just uploaded the following files to the 20220227 release along with their .sha256 files and refreshed SHA256SUMS file:

cpython-3.8.12-aarch64-apple-darwin-debug-20220227T1118.tar.zst
cpython-3.8.12-aarch64-apple-darwin-install_only-20220227T1118.tar.gz
cpython-3.8.12-aarch64-apple-darwin-lto-20220227T1118.tar.zst
cpython-3.8.12-aarch64-apple-darwin-noopt-20220227T1118.tar.zst
cpython-3.8.12-aarch64-apple-darwin-pgo-20220227T1118.tar.zst
cpython-3.8.12-aarch64-apple-darwin-pgo+lto-20220227T1118.tar.zst

I now consider this issue closed.

Note that I haven't thoroughly tested these builds as much as other targets. If you find problems, don't hesitate to file new issues.

mattem commented 1 year ago

@indygreg Sorry for the ping on a closed issue (I can open a new) - is it possible to have a build for 3.8.12 / 3.8.13 for aarch64-linux?

indygreg commented 1 year ago

@indygreg Sorry for the ping on a closed issue (I can open a new) - is it possible to have a build for 3.8.12 / 3.8.13 for aarch64-linux?

Please file a new issue requesting this. I'll have to look into why I didn't support 3.8 when initially rolling out aarch64 Linux builds. But I want to say this is doable.