Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 9/21/05, Guido van Rossum <guido@python.org> wrote:
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea?
I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today. Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output). Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ SystemVersion.plist, which is XML. If you want that info, parsing the file may be more efficient than forking off sw_vers. -wsv On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'?
/usr/bin/sw_vers technically calls a private (at least undocumented) CoreFoundation API, it doesn't parse that plist directly :) On further inspection, it looks like parsing the plist directly is supported API these days (see the bottom of <http:// developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/ gestalt_refchap/chapter_1.4_section_181.html>): import plistlib dct = plistlib.Plist.fromFile('/System/Library/CoreServices/ SystemVersion.plist') print '%(ProductName)s %(ProductVersion)s' % dct -bob On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today.
Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output).
Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ SystemVersion.plist, which is XML. If you want that info, parsing the file may be more efficient than forking off sw_vers.
-wsv
On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'?
Shockingly, it even says that parsing the file is "a better way" than using gestaltSystemVersion(). It's better for python, anyway, I think, since it doesn't require access to the Carbon API set. Be sure to handle the case where the file doesn't exist: import os version_info_file = "/System/Library/CoreServices/ SystemVersion.plist" if os.path.isfile(version_info_file): import plistlib info = plistlib.Plist.fromFile(version_info_file) print '%(ProductName)s %(ProductVersion)s' % info else: uname_os, uname_version = do_the_uname_thing print '%s %s' % (uname_os, uname_version) Or similar. -wsv On Sep 22, 2005, at 10:10 AM, Bob Ippolito wrote:
/usr/bin/sw_vers technically calls a private (at least undocumented) CoreFoundation API, it doesn't parse that plist directly :)
On further inspection, it looks like parsing the plist directly is supported API these days (see the bottom of <http:// developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/ gestalt_refchap/chapter_1.4_section_181.html>):
import plistlib dct = plistlib.Plist.fromFile('/System/Library/CoreServices/ SystemVersion.plist') print '%(ProductName)s %(ProductVersion)s' % dct
-bob
On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today.
Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output).
Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ SystemVersion.plist, which is XML. If you want that info, parsing the file may be more efficient than forking off sw_vers.
-wsv
On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ wsanchez%40wsanchez.net
Bob Ippolito wrote:
/usr/bin/sw_vers technically calls a private (at least undocumented) CoreFoundation API, it doesn't parse that plist directly :)
On further inspection, it looks like parsing the plist directly is supported API these days (see the bottom of <http:// developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/ gestalt_refchap/chapter_1.4_section_181.html>):
import plistlib dct = plistlib.Plist.fromFile('/System/Library/CoreServices/ SystemVersion.plist') print '%(ProductName)s %(ProductVersion)s' % dct
Is the plistlib module always available on Mac OS X ? Could you write a patch to system_alias() which uses the above method if available for Mac OS ?
-bob
On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
"rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on anything we ship today.
Bob's right, the version number from uname only tells you about the kernel, and not whether, for example, the Cocoa API is on the system (it wouldn't be on a standalone Darwin OS install, which will have the same uname output).
Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ SystemVersion.plist, which is XML. If you want that info, parsing the file may be more efficient than forking off sw_vers.
-wsv
On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2005)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Sep 21, 2005, at 11:26 PM, Guido van Rossum wrote:
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea?
No, it's not. There are other mismatches between Mac OS X version and Darwin kernel version (e.g. 10.3.0 and 10.3.1 used the same kernel version). The only correct way to do it with public API is to use gestalt, which platform.mac_ver() does. There are other ways (reading a plist, parsing the output of /usr/bin/sw_vers, using the same SPI that /usr/bin/sw_vers uses...), but gestalt is the only public API. The one caveat with platform.mac_ver() is that it was broken for some version(s) of Python. I don't remember when that was fixed. It definitely works for Python 2.3.5 (ships with Mac OS X 10.4) and Python 2.4.1, but I'm relatively certain it was broken with the Python 2.3.0 that shipped with Mac OS X 10.3, and perhaps also the Python 2.2.0 that shipped with Mac OS X 10.2. Anyway, this information isn't in the uname. You can guess with the uname, but it requires lots of special cases and maintenance. -bob
On 22-sep-2005, at 5:26, Guido van Rossum wrote:
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea?
There's no good reason to assume that the mapping from kernel version to marketing version will stay the same in the future. The savest way to get the marketing version of the currently running OSX is to run / usr/sbin/sw_vers and parse its output. There might also be a public API for getting the same information. Py2app, and specifically the bdist_mpkg component of that, contains code to parse sw_vers output. Ronald
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com
Ronald Oussoren wrote:
On 22-sep-2005, at 5:26, Guido van Rossum wrote:
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea?
There's no good reason to assume that the mapping from kernel version to marketing version will stay the same in the future. The savest way to get the marketing version of the currently running OSX is to run / usr/sbin/sw_vers and parse its output. There might also be a public API for getting the same information. Py2app, and specifically the bdist_mpkg component of that, contains code to parse sw_vers output.
I don't have access to Macs, so there nothing much I can say about this. In general, it's always better to rely on system tools for finding the marketing name of an OS than to try to come up with a work-around. If gestalt() returns the proper name, then this should be used. If sw_vers provides a more reliable way to do this, parsing its output seems like a better idea. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 22 2005)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Thanks all! I won't touch it. /usr/bin/sw_vers is the way to go. On 9/22/05, M.-A. Lemburg <mal@egenix.com> wrote:
Ronald Oussoren wrote:
On 22-sep-2005, at 5:26, Guido van Rossum wrote:
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea?
There's no good reason to assume that the mapping from kernel version to marketing version will stay the same in the future. The savest way to get the marketing version of the currently running OSX is to run / usr/sbin/sw_vers and parse its output. There might also be a public API for getting the same information. Py2app, and specifically the bdist_mpkg component of that, contains code to parse sw_vers output.
I don't have access to Macs, so there nothing much I can say about this.
In general, it's always better to rely on system tools for finding the marketing name of an OS than to try to come up with a work-around. If gestalt() returns the proper name, then this should be used. If sw_vers provides a more reliable way to do this, parsing its output seems like a better idea.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Bob Ippolito -
Guido van Rossum -
M.-A. Lemburg -
Ronald Oussoren -
Wilfredo Sánchez Vega