Hi there! Right. Unless I've done something horribly wrong yet very well hidden, having our setup.py support both setuptools and distutils has turned out to be quite easy! We can now build Python eggs if setuptools are present, and other distribution formats both with and without setuptools. You can see everything I have committed so far here:
http://github.com/mkszuba/pygr/tree/setup_setuptools ALREADY DONE: 1. Import setup and Extension from setuptools by default; if an ImportError is thrown, try pulling them from distutils.core instead. A message is printed to notify the user of switching to fallback mode, too; 2. While working on the above I noticed the line "from distutils.command.build import build" doesn't seem to do anything, as even in distutils mode setup runs just fine without it. Therefore, the line in question has been removed; 3. Setuptools includes transparent support for building Pyrex extensions (which includes using existing .c files from pyrexc), so only involve our Pyrex-loading magic if the setuptools module hasn't been loaded. Note at the first glance doing this by hand in setuptools mode doesn't seem to break anything, then again the module's docs say "You must also not import anything from Pyrex in your setup script." so let's be safe. NOTES: While playing with building different distribution packages I noticed the tests/ directory is included in neither binary nor source packages. Since we would like tests to be included in the latter case, something needs to be done. As far as I can tell there are two options: - hand-craft a manifest file telling distutils/setuptools to include the directory in source packages; - since setuptools understand version control systems, install a Git plug-in for them and have tests/ included in source packages. I am happy to say that the second option works just fine! Just download and install setuptools-git (http://pypi.python.org/pypi/setuptools-git). Beats adding and maintaining a manifest file if your ask me... However, as mentioned above this ONLY works with setuptools. Personally I don't feel this to be a problem, since it's pretty much a one-machine dependency (plus unless we decide to start releasing Git snapshots, building packages won't happen very often) - but even so, I'd like to hear what you think. OUTSTANDING ISSUES: 1. I do not know yet how to have setuptools query Pyrex for its version number so at present it is not checked. We may want to re-enable this check... Then again, given setuptools contains workarounds for various Pyrex bugs, maybe it isn't needed in this mode? Let me know what you think; 2. Invoking tests! As Titus mentioned here recently, it's very easy to get 'setup.py test' work using setuptools - just add something like test_suite = "my_package.tests.test_all" to the setup() call in our setup's main(). Now, how to make such a line invoke code from tests/runtest.py? As far as I can tell with my (very limited) knowledge of Python, loading a package from a different directory than the current one is not trivial. It would of course also make sense to get 'setup.py test' to work in distutils mode as well. However, that is a different story; 3. RPM packages Turns out DEB-package support for distutils is not in the standard library yet so it looks like RPMs are all we'll be able to build for now as far as Linux distro packages are concerned. At the moment rpm (the application) complains about the generated .spec file to be malformed but that should be fairly easy to fix. I'm looking into the matter now. Cheers! -- MS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
