[Distutils] setuptools special case Pyrex and break Cython
Phillip J. Eby
pje at telecommunity.com
Tue Sep 4 21:57:15 CEST 2007
At 09:24 PM 9/4/2007 +0200, Stefan Behnel wrote:
>Stefan Behnel wrote:
> > Phillip J. Eby wrote:
> >> The key design question I ask for setuptools features is "who gets the
> >> pain?", since nearly all design decisions will cause *somebody* pain.
> >> Ideally, I want that pain to go to somebody who's in a position to do
> >> something that improves things for everybody in the long term.
> >> In this case, the only additional pain is for the developers of new
> >> tools that process .pyx files (such as yourself).
> > Wrong. I cannot fix this as a developer of Cython - at least not without
> > providing a fake build_ext.py in a fake Pyrex package, which would make
> > installing Pyrex and Cython on the same machine near impossible and which
> > would break every tool that requires Pyrex instead on Cython.
>Ok, admittedly, I could change sys.path to point it to an internal directory
>of the installed Cython distribution, so that setuptools would be tricked into
>succeeding with a fake Pyrex import - but how ugly is that?
Isn't Cython a *replacement* for Pyrex? If not, then why does it use
.pyx files? If it is, then why is installing both a problem? (It's
not like you can't switch back and forth between them.)
>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"
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.
More information about the Distutils-SIG