I have been packaging up some of my python packages in eggs: http://peak.telecommunity.com/DevCenter/PythonEggs
Basically, an egg has everything you need to use a package, ready-to-run... including binary versions of extensions. It's a nice format because it enables people to just run an "easy_install" program to get a package, no compiler required. (Which is a bigger win on Windows, to be sure, but even on the Mac it means that casual scripters wouldn't need to install Developer Tools). The way eggs are created right now generates a package name that looks something like this: [PackageName]-[Version]-py[PythonVersion]-darwin-8.2.0-Power_Macintosh.egg As coded currently, updating from Mac OS 10.4.1 to 10.4.2 (which bumped the Darwin version from 8.1.0 to 8.2.0), means that any eggs compiled under 10.4.1 won't work any more under 10.4.2, because setuptools is checking the full platform to see if it matches. That's more than a little aggressive, compatibility-wise. We can redefine for Mac OS what an appropriate platform string would be and what the compatibility rules are. That's where I need some help, because I don't know for certain what the compatibility rules are. From reading this list for the past several months, I have an idea: 1) an extension built for Python 2.4 on 10.3 should work under 10.4 2) an extension built for Python 2.4 on 10.4 might work on 10.3, but don't count on it. Would it then make sense for setuptools to do something like this: - declare the platform as it does now (eg, darwin-8.2.0) - specify that an egg is compatible if it's major version (8) is <= your machine's major version. Are there other compatibility gotchas or would that do the trick? Kevin _______________________________________________ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
