Phillip J. Eby wrote:
Isn't Cython a *replacement* for Pyrex?
Sure, but there's some Pyrex code that Cython deliberately does not compile. However, the biggest problem is that most setup.py scripts simply do not use Cython and require Pyrex instead. So users *will* install both.
If it is, then why is installing both a problem? (It's not like you can't switch back and forth between them.)
I might have said it before: this is about supporting setuptools, not about supporting Cython. Supporting Cython is easy: uninstall setuptools, done once and for all. Much less work than installing the right compiler *each time* you want to install a new version of X or want to work on Y.
The right way of fixing this is definitely in setuptools, and the quick fix is to extend the test import of Pyrex.Distutils.build_ext.build_ext with an additional test for Cython.Distutils.build_ext.build_ext in the failure case - if you don't feel like taking the cleaner step of checking for a "build_ext" replacement...
Perhaps you'd care to produce a patch to implement that "cleaner step"? It's not at all obvious to me how to do that without introducing instability that would be unsuitable for an 0.6cN release.
Ok, testing for Cython is as easy as testing for Pyrex, so here's the obvious patch against extension.py that should have gone into 0.6c7. One way of implementing the above change would be to move the replacement code into build_ext rather than Extension. Something like the (untested) build_ext-patcher.py I attached. Note the type check that tests for build_ext being subclassed. Stefan