On Thu, Jun 18, 2009 at 11:05 AM, Ronald Oussoren<ronaldousso...@mac.com> wrote: > The only way to achieve that at the moment is to add some code to setup.py > that explicitly raises an exception when you try to build it on an > unsupported platform.
Or to provide binary releases because python version and os info are set in the archive name. But it's hackish. > The same is true for the python version, pyobjc currently explicitly tests > for python >= 2.3,<3.0 because other versions aren't supported and cause > compile errors (at best, IIRC it will compile with python 2.2 but cause > interpreter crashes when you try to use it). Some Trove classifiers have been added for Python 3 for example, Martin uses it to provide a "Python 3 packages" page at Pypi it's "Programming Language :: Python :: 3" (You have other Python versions as well) There are also an "Operating System ::" classifier. I don't like this very much though, I find it cryptic, and I don't think we can force people+installers to use those classifiers. The other solution is to use the "Requires-Python" Metadadata in PEP 345 and add a "Requires-Platform" when someone wants to mark a source distribution compatibility. And the RPC Interface at pypi provides a method to retrieve them without downloading the package it's : release_data(package_name, version) It would be up to easy_install and such tools, to test those values, prior downloading the package. -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
