[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
New submission from Sam Ferencik: distutils.util.get_platform() semantically differs on (a) Windows and OS X, and on (b) Linux. Windows/OS X: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on a 64-bit system, get_platform() = 'win32'/'macosx-10.6-i386' (32-bit). Linux: the return value is derived from the architecture of the *OS*, hence for 32-bit Python running on 64-bit Linux get_platform() = 'linux-x86_64' (64-bit). Based on a discussion on distutils-sig, the Linux behaviour is probably wrong and should be changed. https://mail.python.org/pipermail/distutils-sig/2013-August/subject.html My context (where this hit me): I was installing the 32-bit version of the Perforce API (compiled module) on 64-bit Windows and on 64-bit Linux. My command-line was python3.3-32 setup.py install --root FOO --install-platlib=lib.$PLAT (note the '-32' and the '$PLAT') On Windows, this installed the 32-bit version of the API into "FOO\lib.win32". On Linux, this installed the 64-bit version of the API into "FOO/lib.linux-x86_64". -- assignee: eric.araujo components: Distutils messages: 197363 nosy: eric.araujo, sferencik, tarek priority: normal severity: normal status: open title: distutils.utils.get_platform() for 32-bit Python on a 64-bit machine type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment:
Unfortunately, I don't have a patch.
Some thoughts:
To discover a 32-bit interpreter running on a 64-bit system, we could use
platform.architecture(), which returns
>>> platform.architecture()
('32bit', 'ELF')
What then, though? How do you turn '32bit' to 'linux-i386'? The naive solution
would be to hard-code this as an exception:
- if 32-on-64, use 'i386'
- otherwise, use os.uname()[4], i.e. 'i386' or 'x86_64'
I suspect that's ultra naive, though. The get_platform() code deals with a
number of Unix-like systems (Solaris, AIX, ...). Even if we accepted this
solution only for Linux, leaving the other OSs broken, is 'i386' always the
right answer, or would 'i586' or similar be appropriate in some cases?
We could also take inspiration from Mac OS (_osx_support.get_platform_osx()),
which basically ignores os.uname()[4] completely and constructs the return value
from a set of hard-coded values ('i386' being one of them).
What do you think?
--
___
Python tracker
<http://bugs.python.org/issue18987>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: Are you asking *what* distutils does? It tackles the problem completely differently on Windows, Unix, and OS X. -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: It's very hacky on all of Windows, Unix, and OS X. That's why I don't feel confident to propose a solution. On Unix, specifically, the return value is heavily based on os.uname(). It seems that the maintainers of OS X have started with the same but then chose to diverge and instead use a list of values. -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: Well, the maintainers of Mac OS didn't consider it a won't fix - and have this working properly. I don't see why we couldn't try to copy what they did. Actually, I think the impact of changing this for 32-bit Python on 64-bit Linux should be quite small, no? -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: Thanks for the context. > A compatibility issue here is that the value provided by get_platform() is > also used outside of Distutils, in particular by pkg_resources (provided by > setuptools) and by pip, in both cases to help determine whether a binary > distribution of an extension module is compatible with the python being used. If your wording is correct, and get_platform() really is used to determine "the python being used," then we could actually be improving things by fixing this. Currently, get_platform() doesn't tell you the bitness of the *python* being used, but the bitness of the *OS* being used (the two of which only differ on 32-on-64). -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: Thanks for the analysis. I agree with you. If there's much push-back, maybe we could introduce an alternative interface, i.e. let get_platform() do its thing, deprecate it, and introduce something like get_interpreter_platform(). -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
Sam Ferencik added the comment: Michael, Thanks for reopening this. You say you're using "64-bit hardware", but what bitness is your OS and the Python interpreter? If you read my original issue description, I only had this issue with 32-bit Python on a 64-bit Linux system (on 64-bit hardware). You say you have 64-bit hardware but are both your AIX and Linux 64-bit? And what about your Python? (Can you try invoking python2.7-32 and python2.7-64 explicitly?) Please add this detail. Thanks, Sam -- ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
