add support for macos 11.0, arm64, universal2

[lawrence-danna-apple]

This updates packaging to know about Mac OS version 11.0, which supports both x86_64 and arm64 arches.

It will allow pip to install x86_64 wheels built for previous versions of Mac OS onto 11.0

see: #318
see: https://discuss.python.org/t/apple-silicon-and-packaging/4516
see: python/cpython#21246

[ned-deily]

I'm not able to add myself as a reviewer but please do not merge this yet. Over in cpython, Ronald and I are working on 11.0 (Big Sur) support including these patches submitted by Apple (thanks!) but we have more work to do first to make sure we are doing the right things across the active branches. We'll let you know when we have reviewed this and are ready to proceed. Thanks!

[brettcannon]

I've made this PR a draft until @ned-deily or another core dev comes back and says upstream CPython is ready for Big Sur and thus we are able to test against upstream appropriately.

[pradyunsg]

Looks like https://bugs.python.org/issue41100 is the CPython tracking issue but it hasn't had much activity over the past 2 months -- @ned-deily @lawrence-danna-apple is that issue the correct place to be looking for the rough status of the blockers for this PR?

[pradyunsg]

Removed the requested reviews -- mostly since it's showing up in my "Reviews Requested" queue, and this isn't actionable at this time.

[ned-deily]

We will be moving forward on that PR soon.

[ronaldoussoren]

the PR looks good to me. The naming for the new set of architectures ("universal2") matches what we're doing in CPython.

[ned-deily]

Looks like this is good to go now. Corresponding support in CPython should land soon (https://bugs.python.org/issue41100).

[lawrence-danna-apple]

@brettcannon, cpython devs have approved, I've removed the "Draft" tag and marked it as ready to review again.

[ned-deily]

LGTM, thanks

[mayeut]

Tests are now failing because of:

packaging/tests/test_tags.py

Line 250 in 9d5273e

((11, 0), "riscv", ["riscv", "universal"]),

but universal shall not be returned for riscv (c.f. https://github.com/python/cpython/blob/v3.9.0/Lib/_osx_support.py#L482)

[pradyunsg]

Thanks @mayeut for catching that! ^>^

[lawrence-danna-apple]

Hi, I'd like to understand this PR better. Before, the version numbering only included the major version numbers (10_15, 10_14, etc.) and not the minor OS version. But since the numbering scheme has changed, now the minor version number is included (11_0). Is that on purpose?

Yes, see the discussion above about this. In order to actually remove the minor version we'd have to coordinate with wheel (and maybe create a PEP?) Instead we just pin the minor version to 0.

[ronaldoussoren]

Pinning the minor to 0 is not really necessary, as you know there are ABI changes between releases of macOS (that is, some variant of macOS 11.x will introduce a new API).

[fxcoudert]

@lawrence-danna-apple it feels there should be a coordinated discussion about this, indeed. See pypa/wheel#385

[fxcoudert]

@ronaldoussoren there should not be a need to include minor version: there was no minor version before, and it worked fine, didn't it?

[lawrence-danna-apple]

@fxcoudert good idea

@ronaldoussoren if we do not pin to zero, what should _mac_binary_formats do? It's not going to know today how many minor versions of Mac OS 11 there will be...

[ronaldoussoren]

I don't mind pinning the value to zero, there's bound to be very few extensions that run into this and those would also have run into this with ABI changes between 10.X.0 and 10.X.Y.

BTW. Is there documentation on the value one should use for "MACOSX_DEPLOYMENT_TARGET"? "MACOSX_DEPLOYMENT_TARGET=11" appears to work.

Anyway, this ship has sailed. There are now wheels with "11.0" for the version on PyPI.

[fxcoudert]

@ronaldoussoren MACOSX_DEPLOYMENT_TARGET=11 is what one would typically use