At 08:09 AM 9/4/2007 +0200, Stefan Behnel wrote:
Phillip J. Eby wrote:
At 06:51 PM 9/3/2007 +0200, Stefan Behnel wrote:
I still prefer the "only fiddle with extensions if build_ext wasn't replaced" way, though.
If build_ext wasn't replaced where and how? Do you mean in the "cmdclass" argument to setup()?
Exactly.
That would mean that you'd have to write code in *every* setup.py to do the replacement -- *and* you'd have to get it correct so that it does the right thing when Pyrex and Cython are *not* installed.
but it would still be better than the current 'feature' enforcement code which basically states: "if Pyrex isn't installed, you can't possibly have meant what you were requesting, so I'll fix your code for you".
...and you simply get a different error message than you were going to get anyway, so there's no net increase in problems. You are going to have to fix the real problem (by either including the .c files or installing the compiler), no matter what. So how does setuptools' action here make any difference? All that changes is the error message.
Problem being that the code isn't broken and the 'fix' breaks it.
After thinking this over some more, I disagree. 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). They have to provide a Pyrex-like build_ext command, but in return they get correct handling for all their setup.py files without having to do anything else. Their users then don't have to jump through setup() hoops, and *their* users don't have to worry about installing the extra tools. On the whole, then, the pain is in the right place, and guides the recipient to the correct action (i.e., implementing a build_ext command, which you've already done). Going the other way would encourage .pyx developers to be sloppy about including .c files, and encourage developers of .pyx tools to be sloppy about making the whole process transparent all the way to the end user. On balance, in other words, I'd rather hurt .pyx-tool developers (population 1 so far as I know) than the people downstream of them. In the long run, my plan is to add entry points to the "build" command so that other commands can be added. This would let you have a command whose job is to turn .pyx files to .c, but only runs if it's installed. In the meantime, faking Pyrex-ness is, IMO, the best way to deal with this.