[Distutils] setuptools special case Pyrex and break Cython

[Phillip J. Eby]

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.