Building thin arm64 wheels for MacOS 12+

[tylerjereddy]

To avoid a kernel panic with older OS versions/M1, I've been trying to build MacOS version 12 arm64 thin wheels for SciPy (MacPython/scipy-wheels#144).

I'm not sure if this is a bug or just a request for suggestions/features, but at the moment this is presenting me with two main challenges:

• for Python 3.10, the wheel is built, although the name may suggest an older version of MacOS: scipy-1.8.0.dev0+2082.296b550-cp310-cp310-macosx_11_0_arm64.whl (I'm not sure if an acceptable route forward here is to i.e., rename the wheel manually later + disable the test stage on CI since we don't have access to the hardware anyway?)
• for Python 3.8 and 3.9, specifying MacOS version 12 will block the download of Python itself, with faulty links like https://www.python.org/ftp/python/3.9.7/python-3.9.7-macosx12.0.pkg; how crucial is it that I specify MB_PYTHON_OSX_VER: "12.0" if we want to enforce usage of the wheels for only >= 12? Alternatively, maybe we can just adjust the links in multibuild or something?

[tylerjereddy]

cc @rgommers in case I've said something incorrectly; sorry if this is mostly just a "query," but better to ask about this early I think

[rgommers]

I'm not sure if an acceptable route forward here is to i.e., rename the wheel manually later + disable the test stage on CI since we don't have access to the hardware anyway

Yes that sounds good and should be safe.

how crucial is it that I specify MB_PYTHON_OSX_VER: "12.0" if we want to enforce usage of the wheels for only >= 12? Alternatively, maybe we can just adjust the links in multibuild or something?

I think we can do the same here - specify 11.0 and rename the wheels to 12_0 afterwards.

[tylerjereddy]

great, thanks, I'll try this right away to see where we stand

[isuruf]

Correct variable to set is MACOSX_DEPLOYMENT_TARGET which would make pip use the correct wheel tag name

[rgommers]

Correct variable to set is MACOSX_DEPLOYMENT_TARGET which would make pip use the correct wheel tag name

Ah. I always thought about that as a backwards compatibility env var to pick a different SDK. Given that an older macOS likely does not have an SDK / knowledge of APIs of future OS versions, this didn't seem relevant. But I guess you're right; the 11.x APIs will work on 12.0, so this is still communicating the right thing.

Let's try to change to that in master.