Add intel cpu_arch on MacOS as universal-compatible

[pradyunsg]

As noted in #319 (comment)

Identified in pypa/pip#9170.

[wiggin15]

Why do we add only "universal" and not "universal2" for "intel"? (I'm not sure when this arch name is used)

[pradyunsg]

See https://github.com/python/cpython/blob/41761933c1c30bb6003b65eef1ba23a83db4eae4/Mac/README.rst#21-flavors-of-universal-binaries

intel refers to a universal binary that works on i386 and x86_64 -- which are both supported by universal.

[pradyunsg]

The slightly broader question here is whether we want to allow universal architectures (i.e. architectures used to refer to binaries that work on multiple ISAs) to be passed into this function as cpu_arch.

As on today, there's only 1 special case involved here: intel and it was (unintentionally?) permitted in earlier releases -> universal wheels would be OK if you pass in intel as the cpu_arch.

Looking at the downstream pip implementation of allowing users to pass in custom tags, and given that there's only 1 special case we allow today, I feel like it is only natural to conclude "yes, we should allow this". :)

[brettcannon]

@ned-deily @ronaldoussoren does this change make sense to you?

@pradyunsg I think you're right, but I just want the Mac expert's opinion. But if you don't hear from anyone within a day and need to get this out for pip then I'm fine merging it.

[pradyunsg]

Sure! I don't mind waiting here and am 100% on board for waiting on a Mac expert's opinion.

As noted in pypa/pip#9170 (comment), I don't think a large group of people are gonna hit this issue, but it'd still be nice to have a fix sometime reasonably soon.

[ronaldoussoren]

Assuming _mac_binary_formats(.., cpu_arch) returns the list of cpu tags compatible with cpu_arch adding "universal" to the result when cpu_arch is "intel" is fine as "universal" is a 4-way fat binary including both architectures present in the 2-way fat binaries denoted by "intel".

That said, it is highly unlikely that you'll ever run into these. AFAIK we've never shipped "universal" installers for CPython.

[pradyunsg]

AFAIK we've never shipped "universal" installers for CPython.

LOL

Seems like this is purely theoretical use case then? I genuinely don't think anyone other than CPython devs are building CPython's MacOS Installers.

[ned-deily]

LGTM, too. Thanks!

BTW, there are builders and users of universal macOS binaries other than just for python.org downloadable installers. For example, third-party apps written in Python generally need to include a copy of Python that may be built by the app developer and there are probably still some apps being shipped that still support the intel variant of universal builds (i.e. intel-32 and intel-64). But it is true, as Ronald points out, that many of the defined variants are likely barely used anymore (and in particular the universal universal (4-way) variant's time came and went pretty quickly). OTOH, the cost to keep supporting them seems very low; easier than trying to find out who might still may be using them.