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" >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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
