'.' removed from platform names

[mdavidsaver]

In trying to figure out how to build wheels of OSX I (naively?) tried:

python -m setup.py -p macosx_10_6_intel.macosx_10_6_x86_64

I find that the resulting .whl is named cythonxx_demo-0.0.0-cp37-cp37m-macosx_10_6_intel_macosx_10_6_x86_64.whl and the WHEEL file contains

Tag: cp37-cp37m-macosx_10_6_intel_macosx_10_6_x86_64

Based on PEP 491 and some reading I was expecting this to be cythonxx_demo-0.0.0-cp37-cp37m-macosx_10_6_intel.macosx_10_6_x86_64.whl (with a .) and:

Tag: cp37-cp37m-macosx_10_6_intel
Tag: cp37-cp37m-macosx_10_6_x86_64

Though my expectations may very well be wrong. I don't claim to have a good understanding of how OSX platform names are used.

Looking into the code I see an apparent conflict. plat_tag is expected to contains dots (.).

wheel/wheel/bdist_wheel.py

Lines 275 to 279 in b227ddd

	impl_tag, abi_tag, plat_tag = self.get_tag()
	for impl in impl_tag.split('.'):
	for abi in abi_tag.split('.'):
	for plat in plat_tag.split('.'):
	msg['Tag'] = '-'.join((impl, abi, plat))

But get_tags() has already replaced these.

wheel/wheel/bdist_wheel.py

Line 156 in b227ddd

plat_name = plat_name.replace('-', '_').replace('.', '_')

[jamadden]

For macOS, intel in a platform tag indicates a universal binary: gevent-1.4.0-cp36-cp36m-macosx_10_6_intel.whl will work with 32 and 64-bit processors. x86_64 is only for 64-bit, and i686 is only for 32-bit; specifying the two together is redundant, or only specifying one with intel is incorrect.

The simplest and most compatible way I've found to distribute wheels for macOS is to install the standard Python packages from python.org and build the wheels using them. These install into /usr/local and don't interfere with the system Python or those built by macports (I can't speak to homebrew). Effectively, these packages define the baseline platform tag, and wheels built with them can be installed on interpreters from python.org, built with homebrew, or custom built. These all used to be universal binaries and generated intel wheels, but I'm not sure that's true anymore, especially since Apple no longer supports 32-bit hardware.

[mdavidsaver]

I am building using the python.org binaries.

What you say about intel vs. x86_64 matches what I have read elsewhere. However, I'm struggling to understand this in relation to what I see uploaded to pypi.org.

On the one hand I find Cython.

Cython-0.29.13-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl

Which explicitly mentions both intel and x86_64, as well as several macosx version (10.6, 10.9, and 10.10).

On the other I find numpy with a far shorter:

numpy-1.17.2-cp37-cp37m-macosx_10_6_intel.whl

Is there some history to explain this difference? Was this verbosity necessary in the past?

I guess I should follow what is done for numpy?

[jamadden]

Yes, there are (very) historic reasons for expansive naming, but even Cython is stopping doing that. See matthew-brett/multibuild@02777c9#diff-c6138a165d27a77acc4f03c58856b4de

[mdavidsaver]

Thanks for the clarification.

I guess the expansive . syntax is platform names is being deprecated and the inconsistency I noted above is not a bug?

As a note I found the output of pip._internal.pep425tags.get_supported() to be very informative in identifying which tags pip will consider for a given target. Answered some questions I didn't know I had.

[xavfernandez]

As a note I found the output of pip._internal.pep425tags.get_supported() to be very informative in identifying which tags pip will consider for a given target. Answered some questions I didn't know I had.

Somewhat unrelated to the issue, but since pip 19.2, pip debug --verbose is available to provide the info.