Fix cp38-macosx universal2 and arm64 Python pkg URL

[hombit]

Previous URLs pointed to x86_64 version

[joerick]

Unfortunately we don't want to upgrade the bundled Python because it would increase the minimum MacOS version for the x86_64 arch from 10.9 to 11.0, which is a pretty massive jump.

[hombit]

Sorry, could you please explain how arm64 Python URL affects x86_64 minimum macOS version?

[Czaki]

here you update also python to build universal2 wheels. universal2 wheels are wheels that contain code for both x86 and arm. This python version does not allow to build wheels against x86 for macos 10.9.

[hombit]

Should I update arm64 URL only?

[hombit]

I still don't understand, sorry. For Python 3.9 and 3.10 both arm64 and universal2 URLs points to universal2 packages, while all python 3.8 URLs are for the x86_64 package. Why is it different for different Python versions?

[Czaki]

I do not play too much with ARM on macOS so let's wait for what @joerick will tell.

[joerick]

Ah, I understand what's going on. We still have no arm64 CI, so we've never actually had a chance to test running all this on arm64. The version of 3.8 that we install only runs on x86_64. So when you run it on arm64, it's emulating x86_64. The wheel that you built is fine, but you're not able to test it.

This PR seems to only change the universal2/arm64 build identifiers. I don't think that will change anything, as on macOS you can only have one minor version of Python installed at once, and the first one that cibuildwheel finds, it will install. So if we were going to make this change we'd have to change all three 3.8 URLs.

The Python 3.8 arm64 support was added in #704. I don't have time right now but perhaps there are some clues in there why we're not using the macos11 versions.

[henryiii]

We tried very hard to use this when it came out, but it doesn’t work. CPython only has partial support for 3.8 on ARM - it was squeezed in at the last minute in the last binary release. IIRC you can’t produce 10.9-10.15 compatible wheels for Intel from the ARM version since Python didn’t include a 10.9 compatible Intel version in the binary, like they normally do (and do in 3.9+). You can look at the PR where 3.8 was added, I think.

I think to make this “work” we’d need to special case when running on ARM and have the (big) caveat that you can’t build for macOS 10 from AS (but only for 3.8). Is 3.8 still the version Apple ships? I’m traveling and won’t be my AS machine till the 27th.

[henryiii]

Read here:

• [Bot] Update dependencies #663 (comment)
• macOS arm64 requires numpy 1.20.0 or above scipy/oldest-supported-numpy#20 (comment)
• feat: support building universal/arm64 from x64_86 Python 3.8 #704

I think we should see if we can build from AS too, but we haven’t had CI runners for it and it will take some changes and should error out of macOS version is set <11.

I’m pretty sure we use the AS version from this table when building pure AS wheels from Intel.

[mayeut]

IIRC you can’t produce 10.9-10.15 compatible wheels for Intel from the ARM version since Python didn’t include a 10.9 compatible Intel version in the binary, like they normally do (and do in 3.9+).

Now that MACOSX_DEPLOYMENT_TARGET is always set, I don't think there's a big issue on what you can target (i.e. will still be 10.9 for x86_64) unless I'm missing something. However, using a macOS 10.x runner to do the build won't be possible anymore with this installer which requires macOS 11+.

[henryiii]

From what I understand, you can't set MACOSX_DEPLOYMENT_TARGET lower than whatever CPython was prepared with, otherwise we'd not need to download the official binaries at all. I could be wrong, but I'm pretty sure MACOSX_DEPLOYMENT_TARGET can only be increased.

[Czaki]

yes. here is a wheel code fragment with a warning about this:

https://github.com/pypa/wheel/blob/9d4264d2f23ea44dd85639a27fa6b284261921cd/src/wheel/macosx_libfile.py#L411-L419

[joerick]

Thanks all for the informative discussion. I guess the upshot is that we keep the macos10.9 installer, and we can't test 3.8 arm64 wheels, even when running on arm64.

However, we should change the behaviour when running on Apple Silicon, to not try to test the arm64 3.8 wheel, and include an informative message explaining why.

[joerick]

Just a note for anyone finding this now that arm64 runners are more widely available. If it's important to you to test the cp38 arm64 wheels, there's a workaround.

You can choose to install a different version of Python 3.8 on your runner before invoking cibuildwheel:

curl -fsSLO https://www.python.org/ftp/python/3.8.10/python-3.8.10-macos11.pkg
sudo installer -pkg python-3.8.10-macos11.pkg -target /
# ... invoke cibuildwheel ...

Just be aware that if you use this Python to build x86_64 wheels too, this increases the minimum supported macOS version on x86_64 to 11.0.

[joerick]

For reference, this gives an idea of which Python 3.8 users are using which OS.

That's the last 30 days, from our stats spreadsheet

[henryiii]

Do you have your old python versions the last month plot? That was interesting to see the fraction of 3.8 ARM users. I also don't remember what the default Python version was for those versions. I'm on the latest macOS and I see 3.9 in my /usr/bin, so the've finally updated (a little).

[joerick]

Though I have no idea what's going on with the Python 2.7 arm64 users!? I guess that Homebrew offers a build of that?

[henryiii]

I don't think they do, I don't think there's an open source 2.7 for AS, and homebrew doesn't offer 2.7 anymore. But Apple provided their own patched version in macOS 11 - 12.3.