[Distutils] setuptools special case Pyrex and break Cython
Phillip J. Eby
pje at telecommunity.com
Tue Sep 4 18:43:45 CEST 2007
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()?
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.
More information about the Distutils-SIG