classification
Title: Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7
Type: behavior Stage: resolved
Components: Distutils, Library (Lib), Macintosh Versions: Python 3.3, Python 3.2
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: Matthew.Scott, eric.araujo, ned.deily, tarek
Priority: normal Keywords:

Created on 2012-04-04 20:49 by Matthew.Scott, last changed 2012-04-04 22:03 by ned.deily. This issue is now closed.

Messages (5)
msg157504 - (view) Author: Matthew Scott (Matthew.Scott) Date: 2012-04-04 20:49
Using Python 3.2.2 and Python 3.3.0a2 (installed via 64-bit installers in official DMGs on python.org), 'distutils.util.get_platform()' returns an incorrect OS version when running on Mac OSX 10.7.

Using Python 2.6.7, and Python 2.7.1 (the versions included with Mac OSX), the output indicates 'macosx-10.7' correctly.

> for version in 2.6 2.7 3.2 3.3; do python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.7-intel
2.7.1 macosx-10.7-intel
3.2.2 macosx-10.6-intel
3.3.0a2 macosx-10.6-intel

Some packages make use of this in their setup.py to determine the proper location of libraries.

For example, the 'readline' distribution's setup.py does so here: https://github.com/ludwigschwardt/python-readline/blob/6f0e801fa1632fcbb0e005eb9709aaa6051a0f28/setup.py#L33

It fails due to the incorrect assumption that it's running on 10.6 instead of 10.7.  Excerpt from "python setup.py bdist_egg":

building 'readline' extension
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk
Please check your Xcode installation
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DHAVE_RL_CALLBACK -DHAVE_RL_CATCH_SIGNAL -DHAVE_RL_COMPLETION_APPEND_CHARACTER -DHAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK -DHAVE_RL_COMPLETION_MATCHES -DHAVE_RL_COMPLETION_SUPPRESS_APPEND -DHAVE_RL_PRE_INPUT_HOOK -I. -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c Modules/3.x/readline.c -o build/temp.macosx-10.6-intel-3.2/Modules/3.x/readline.o -Wno-strict-prototypes -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64
In file included from Modules/3.x/readline.c:8:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:11:20: error: limits.h: No such file or directory
msg157505 - (view) Author: Matthew Scott (Matthew.Scott) Date: 2012-04-04 21:02
In the cases of both Python 3.x and 2.x, get_platform() is deriving information about the version of OSX from the 'MACOSX_DEPLOYMENT_TARGET' dictionary returned by distutils.sysconfig.get_config_vars().

Using Python 3.2.2:
In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET']
Out[1]: '10.6'

Using Python 2.7.1:
In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET']
Out[1]: '10.7'

While the deployment target seems like a useful source of information, it does not seem to be accurate enough to "Return a string that identifies the current platform" as the docstring for distutils.util.get_platform() suggests.
msg157507 - (view) Author: Matthew Scott (Matthew.Scott) Date: 2012-04-04 21:10
Interestingly, the 2.x series allowed an os.environ override for the MACOSX_DEPLOYMENT_TARGET value, while the 3.x series did away with that, as a result of http://bugs.python.org/issue9516

> for version in 2.6 2.7 3.2 3.3; do MACOSX_DEPLOYMENT_TARGET=10.42 python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done
2.6.7 macosx-10.42-intel
2.7.1 macosx-10.42-intel
3.2.2 macosx-10.6-intel
3.3.0a2 macosx-10.6-intel
msg157509 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-04-04 21:50
For OS X builds, the value returned in get_platform() is not intended to indicate what OS version the Python instance is running on.  Rather, it indicates which ABI version was used to build the Python in use so that Distutils can use the same ABI for building C extension modules.  The ABI is determined by the value of MACOSX_DEPLOYMENT_TARGET at build time.  In this case, a value of "macosx_10.6-intel" means the resulting executables and object files are a universal build with both 32-bit (i386) and 64-bit (x64_64) Intel architectures and can run on Mac OS X 10.6 and higher.  The reason the Apple-supplied system Pythons have a value of 10.7 is that they are built with a deployment target of 10.7; they have no need to run on earlier version of OS X.

The issue with the readline extension build you cite is the error "Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk".  Chances are you are using the most recent Xcode release (4.3.x) from Apple which unfortunately moved the location of the SDKs from /Developer, which now no longer is used by Xcode, to within the Xcode.app bundle itself, now located in /Applications.  A workaround for Xcode 4.3 is to install a symlink to the old location:

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer
msg157512 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-04-04 22:03
BTW, Issue14499 is now open to track the Xcode 4.3 SDK problem.
History
Date User Action Args
2012-04-04 22:03:40ned.deilysetmessages: + msg157512
2012-04-04 21:50:50ned.deilysetstatus: open -> closed

nosy: + ned.deily
messages: + msg157509

resolution: rejected
stage: resolved
2012-04-04 21:10:30Matthew.Scottsetmessages: + msg157507
2012-04-04 21:02:15Matthew.Scottsetmessages: + msg157505
2012-04-04 20:49:28Matthew.Scottcreate