distutils.util.get_platform() - Linux vs Windows
Hi, It seems distutils.util.get_platform() semantically differs on Windows and Linux. Windows: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on 64-bit Windows get_platform() = 'win32' (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). Is this intentional? My context (where this hit me): I was trying to install 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". I'm not sure which is more correct behavior but the asymmetry seems suspicious. Sam _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________
On Fri, Aug 16, 2013 at 2:18 AM, <samuel.ferencik@barclays.com> wrote:
It seems distutils.util.get_platform() semantically differs on Windows and Linux.
Windows: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on 64-bit Windows get_platform() = 'win32' (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).
Is this intentional?
This seems just plain wrong to me. For the record, running a 32 bit Python on a 64 bit OS_X box: In [5]: distutils.util.get_platform() Out[5]: 'macosx-10.6-i386' which is the answer I want. -Chris
My context (where this hit me): I was trying to install 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". I'm not sure which is more correct behavior but the asymmetry seems suspicious.
Sam _______________________________________________
This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer.
For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.
_______________________________________________ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Monday, August 19, 2013 7:13 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Fri, Aug 16, 2013 at 2:18 AM, <samuel.ferencik@barclays.com> wrote:
It seems distutils.util.get_platform() semantically differs on Windows and Linux.
Windows: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on 64-bit Windows get_platform() = 'win32' (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).
Is this intentional?
This seems just plain wrong to me.
For the record, running a 32 bit Python on a 64 bit OS_X box:
In [5]: distutils.util.get_platform() Out[5]: 'macosx-10.6-i386'
which is the answer I want.
-Chris
Chris, What does your 'uname -m' return? Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195] Basically, you're saying that the return value is wrong on Linux and correct on Windows, right? That get_platform() should return "32-bit" for a 32-bit process running on a 64-bit system. TBH, I was expecting the opposite; to me, "platform" means the OS, which would mean that Linux does well to derive the return value from the OS's architecture. Sam _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________
AFAIK Wheel is using that to determine binary compatibility, so if a 32bit Python on a 64bit Linux needs to be linux_32 that could be a problem. On Aug 20, 2013, at 2:15 AM, <samuel.ferencik@barclays.com> wrote:
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Monday, August 19, 2013 7:13 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Fri, Aug 16, 2013 at 2:18 AM, <samuel.ferencik@barclays.com> wrote:
It seems distutils.util.get_platform() semantically differs on Windows and Linux.
Windows: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on 64-bit Windows get_platform() = 'win32' (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).
Is this intentional?
This seems just plain wrong to me.
For the record, running a 32 bit Python on a 64 bit OS_X box:
In [5]: distutils.util.get_platform() Out[5]: 'macosx-10.6-i386'
which is the answer I want.
-Chris
Chris,
What does your 'uname -m' return? Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
Basically, you're saying that the return value is wrong on Linux and correct on Windows, right? That get_platform() should return "32-bit" for a 32-bit process running on a 64-bit system. TBH, I was expecting the opposite; to me, "platform" means the OS, which would mean that Linux does well to derive the return value from the OS's architecture.
Sam
_______________________________________________
This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer.
For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.
_______________________________________________ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Aug 19, 2013 at 11:15 PM, <samuel.ferencik@barclays.com> wrote:
What does your 'uname -m' return?
x86_64
Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
nope -- I am quite deliberately running a 32 bit Python on my 64 bit OS (I have some custom code C++ I"m using that is not yet 64 bit safe).
return value is wrong on Linux and correct on Windows, right?
no -- I'm saying that it's right on Windows (and OS-X), but wrong on Linux.
That get_platform() should return "32-bit" for a 32-bit process running on a 64-bit system.
yes, it should.
TBH, I was expecting the opposite; to me, "platform" means the OS, which would mean that Linux does well to derive the return value from the OS's architecture.
except what would be the utility of that? this is a call made within python, and it's part of distutils, so what the caller wants to know is the platform that this particular python was build for, NOT the platform is happens to be running on. i.e. what platform do I want to build binary extensions for, and/or what platform do I want to download binary wheels for. So I'm pretty sure that currently Windows and OS-X have it right, and Linux is broken. I'm guessing running 32 bit python on a 64 bit LInux is not that common, however. (and it's less common to download binaries...) To add complexity, if I run the Apple-supplied python2.7.1 (which is 32_64 bit universal, but runs 64 bit on my machine), I get:
distutils.util.get_platform() 'macosx-10.7-intel'
Which is more useful than it may look at first -- "intel" means "both intel platforms", i.e. i386 and x86_64. and 10.7 means -- built for OS-X 10.7 and above. so I think it's doing the right thing. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Tuesday, August 20, 2013 5:47 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Mon, Aug 19, 2013 at 11:15 PM, <samuel.ferencik@barclays.com> wrote:
What does your 'uname -m' return?
x86_64
Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
nope -- I am quite deliberately running a 32 bit Python on my 64 bit OS (I have some custom code C++ I"m using that is not yet 64 bit safe).
That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() derives the value from uname for OS X, similar to Linux. (osname, host, release, version, machine) = os.uname() ... elif osname[:6] == "darwin": import _osx_support, distutils.sysconfig osname, release, machine = _osx_support.get_platform_osx( distutils.sysconfig.get_config_vars(), osname, release, machine) return "%s-%s-%s" % (osname, release, machine) so I would expect "uname -m" to be in line with get_plaform(). But maybe I'm misreading that... Also, I don't have access to the _osx_support source code.
return value is wrong on Linux and correct on Windows, right?
no -- I'm saying that it's right on Windows (and OS-X), but wrong on Linux.
I think you have misread my sentence, and we actually agree here. What's the next action? Report a Python bug? (That's a cultural question; I'm new to Python.) Regards, Sam
That get_platform() should return "32-bit" for a 32-bit process running on a 64-bit system.
yes, it should.
TBH, I was expecting the opposite; to me, "platform" means the OS, which would mean that Linux does well to derive the return value from the OS's architecture.
except what would be the utility of that? this is a call made within python, and it's part of distutils, so what the caller wants to know is the platform that this particular python was build for, NOT the platform is happens to be running on. i.e. what platform do I want to build binary extensions for, and/or what platform do I want to download binary wheels for.
So I'm pretty sure that currently Windows and OS-X have it right, and Linux is broken. I'm guessing running 32 bit python on a 64 bit LInux is not that common, however. (and it's less common to download binaries...)
To add complexity, if I run the Apple-supplied python2.7.1 (which is 32_64 bit universal, but runs 64 bit on my machine), I get:
distutils.util.get_platform() 'macosx-10.7-intel'
Which is more useful than it may look at first -- "intel" means "both intel platforms", i.e. i386 and x86_64. and 10.7 means -- built for OS-X 10.7 and above.
so I think it's doing the right thing.
-Chris
_______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________
On Tue, Aug 20, 2013 at 9:00 AM, <samuel.ferencik@barclays.com> wrote:
That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() derives the value from uname for OS X, similar to Linux.
(osname, host, release, version, machine) = os.uname() ... elif osname[:6] == "darwin": import _osx_support, distutils.sysconfig osname, release, machine = _osx_support.get_platform_osx( distutils.sysconfig.get_config_vars(), osname, release, machine) return "%s-%s-%s" % (osname, release, machine)
so I would expect "uname -m" to be in line with get_plaform(). But maybe I'm misreading that... Also, I don't have access to the _osx_support source code.
yup -- _osx_support.get_platform_osx() does special magic....
return value is wrong on Linux and correct on Windows, right?
no -- I'm saying that it's right on Windows (and OS-X), but wrong on Linux.
I think you have misread my sentence, and we actually agree here.
duh! yes, we do.
What's the next action? Report a Python bug? (That's a cultural question; I'm new to Python.)
not sure -- this seems like the right place to report it, but an offical bug report may make sense. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 20 Aug, 2013, at 18:00, samuel.ferencik@barclays.com wrote:
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Tuesday, August 20, 2013 5:47 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Mon, Aug 19, 2013 at 11:15 PM, <samuel.ferencik@barclays.com> wrote:
What does your 'uname -m' return?
x86_64
Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
nope -- I am quite deliberately running a 32 bit Python on my 64 bit OS (I have some custom code C++ I"m using that is not yet 64 bit safe).
That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() derives the value from uname for OS X, similar to Linux.
(osname, host, release, version, machine) = os.uname() ... elif osname[:6] == "darwin": import _osx_support, distutils.sysconfig osname, release, machine = _osx_support.get_platform_osx( distutils.sysconfig.get_config_vars(), osname, release, machine) return "%s-%s-%s" % (osname, release, machine)
so I would expect "uname -m" to be in line with get_plaform(). But maybe I'm misreading that... Also, I don't have access to the _osx_support source code.
_osx_support is a pure python module in the stdlib, the source is in the usual location. The behavior on OSX is quite intentional and ensures that disutils binary archive names correctly reflect the use of fat binaries and the minimal supported OSX release. The only thing that might need change is the name of the supported architectures, the wheel spec has a better way to indicate multiple executable architectures than making up names for every set of architectures that we care to support, but to be honest I haven't had time yet to fully ingest the spec and work out if is completely useful for fat binaries on OSX.
return value is wrong on Linux and correct on Windows, right?
no -- I'm saying that it's right on Windows (and OS-X), but wrong on Linux.
I think you have misread my sentence, and we actually agree here.
What's the next action? Report a Python bug? (That's a cultural question; I'm new to Python.)
http://bugs.python.org/ Ronald
-----Original Message----- From: Ronald Oussoren [mailto:ronaldoussoren@mac.com] Sent: Thursday, August 22, 2013 12:21 PM To: Ferencik, Samuel: Markets (PRG) Cc: chris.barker@noaa.gov; distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On 20 Aug, 2013, at 18:00, samuel.ferencik@barclays.com wrote:
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Tuesday, August 20, 2013 5:47 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Mon, Aug 19, 2013 at 11:15 PM, <samuel.ferencik@barclays.com> wrote:
What does your 'uname -m' return?
x86_64
Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
nope -- I am quite deliberately running a 32 bit Python on my 64 bit OS (I have some custom code C++ I"m using that is not yet 64 bit safe).
That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() derives the value from uname for OS X, similar to Linux.
(osname, host, release, version, machine) = os.uname() ... elif osname[:6] == "darwin": import _osx_support, distutils.sysconfig osname, release, machine = _osx_support.get_platform_osx( distutils.sysconfig.get_config_vars(), osname, release, machine) return "%s-%s-%s" % (osname, release, machine)
so I would expect "uname -m" to be in line with get_plaform(). But maybe I'm misreading that... Also, I don't have access to the _osx_support source code.
_osx_support is a pure python module in the stdlib, the source is in the usual location.
Of course it is. I don't know where I was looking. Basically, get_platform_osx() overrides the value of 'machine' passed in. So in distutils.util.get_platform() it looks like it's doing a similar thing as for Linux (uname) but it then throws it away and lets _osx_support.get_platform_osx() do its own thing.
The behavior on OSX is quite intentional and ensures that disutils binary archive names correctly reflect the use of fat binaries and the minimal supported OSX release.
The only thing that might need change is the name of the supported architectures, the wheel spec has a better way to indicate multiple executable architectures than making up names for every set of architectures that we care to support, but to be honest I haven't had time yet to fully ingest the spec and work out if is completely useful for fat binaries on OSX.
return value is wrong on Linux and correct on Windows, right?
no -- I'm saying that it's right on Windows (and OS-X), but wrong on Linux.
I think you have misread my sentence, and we actually agree here.
What's the next action? Report a Python bug? (That's a cultural question; I'm new to Python.)
Thanks, I'll report one. Sam _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________
On 20 Aug, 2013, at 8:15, samuel.ferencik@barclays.com wrote:
-----Original Message----- From: Chris Barker - NOAA Federal [mailto:chris.barker@noaa.gov] Sent: Monday, August 19, 2013 7:13 PM To: Ferencik, Samuel: Markets (PRG) Cc: distutils-sig@python.org Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
On Fri, Aug 16, 2013 at 2:18 AM, <samuel.ferencik@barclays.com> wrote:
It seems distutils.util.get_platform() semantically differs on Windows and Linux.
Windows: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on 64-bit Windows get_platform() = 'win32' (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).
Is this intentional?
This seems just plain wrong to me.
For the record, running a 32 bit Python on a 64 bit OS_X box:
In [5]: distutils.util.get_platform() Out[5]: 'macosx-10.6-i386'
which is the answer I want.
-Chris
Chris,
What does your 'uname -m' return? Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195]
disutils.util.get_platform() on OSX returns the "architecture" supported by the current binary. I get: :>>> distutils.util.get_platform() 'macosx-10.8-intel' This means that Python was build for a deployment target of 10.8 (that is, the binary runs on OSX 10.8 or later) and supports the 'intel' set of architecures (i386 and x86_64). Ronald
participants (4)
-
Chris Barker - NOAA Federal -
Donald Stufft -
Ronald Oussoren -
samuel.ferencik＠barclays.com