Python 3.4 pip install wheel fails on Yosemite - "not a supported wheel on this platform"

Question

I've been trying to install numpy, pysci etc on a MacBook Pro with Yosemite and fresh installation of ActiveState Python 3.4. I have tried many wheel files and they all fail with "not a supported wheel on this platform". For example, using the latest wheel file for Python 3.4 from https://pypi.python.org/pypi/numpy:

...$ sudo pip3 install numpy-1.9.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl

numpy-1.9.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl is not a supported wheel on this platform.

I traced my way through wheel.py, req.py and pep425tags.py to try to understand why it failed. In pep425tags.py it uses

distutils.util.get_platform().replace('.', '_').replace('-', '_')

which, presumably, is then compared to tags in the filename of the wheel file.

Since I have upgraded to Yosemite, I was expecting that my computer would return something like: "macosx_10_10_intel" or "macosx_10_10_x86_64" - but instead it returns "macosx_10_6_x86_64"

>>> import distutils.util
>>> distutils.util.get_platform().replace('.', '_').replace('-', '_')
'macosx_10_6_x86_64'
>>> 

Am I correct that Yosemite is apparently reporting that it is Snow Leopard? Or is Python 3.4 getting it wrong? Is this my problem with wheel files? If so, is there a fix?

---

Updating to Python 3.4.2 corrected the problem and I was able to install the numpy wheel file. Please note however, that distutils.util.get_platform() still reports "macosx_10_6_intel" but that does not affect the installation.

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  5 2014, 20:42:22) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> import distutils.util
>>> distutils.util.get_platform().replace('.', '_').replace('-', '_')
'macosx_10_6_intel'

Answer 1

Take into account that distutils.util.get_platform() returns the minimal version on which the binary will run:

For Mac OS X systems the OS version reflects the minimal version on which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET during the build of Python), not the OS version of the current system.

Emphasis mine. That said, for Python 3.4 you can reasonably expect the value to be 10.10 if you built Python on that platform.

For Python to handle MACOSX_DEPLOYMENT_TARGET to work correctly throughout, you need to upgrade to Python 3.4.2; 3.4.1 is not ready for Mac OS X 10.10 or higher. See issue #21811:

There are a number of places within the cpython code base where decisions are made based on either the running system version or the OS X ABI (e.g. the value of MACOSX_DEPLOYMENT_TARGET) that the interpreter was built with or is being built with. Most of the current tests do string comparisons of these values which will not work properly with a two-digit version number ('10.10' < '10.9' --> True).

3.4.2 includes the required fixes. The same applies to Python 2.7 up to version 2.7.7; if you see this same problem in Python 2.7 upgrade to 2.7.8 or up.

Without the fixes, intel is mixed up with x86_64, as is the case with your setup:

1. When running current 3.4.1 and 2.7.7 binary installers on 10.10, building C extension modules will likely result in an incorrect universal platform name, for example, "x86_64" instead of "intel", and that could affect extension module file names and wheel or egg names.

For reference, on my OS X 10.10 system, on Python 3.4.2 the result of get_platform() is:

>>> import distutils.util
>>> distutils.util.get_platform()
'macosx-10.10-x86_64'

and for Python 2.7.8 I get:

>>> import distutils.util
>>> distutils.util.get_platform()
'macosx-10.4-x86_64'