[SciPy-dev] weave.inline broken by setuptools?
Thu Sep 25 23:47:51 CDT 2008
On Thu, Sep 25, 2008 at 9:34 PM, Robert Kern <firstname.lastname@example.org> wrote:
>> since otherwise we basically get a ticking time bomb. On the other
>> hand, I imagine this might have its own nasty problems, so perhaps
>> it's a dumb idea.
> You personally asked us not to do that. That meant that you would
> always be using setuptools to install numpy just because you had it on
> your system rather than because you chose to use it to install numpy.
Hence the 'dumb idea' note, I kind of knew that :) I know I've been
one of the most vocal complainers about hidden setuptools imports...
But I'm wondering if there couldn't be a clean solution to this at
least in the new forked setuptools: if setuptools is so dangerous to
pull in once distutils has been loaded, perhaps it could check that
it's always the first to do the distutils import? Something like
if 'distutils' in sys.modules:
raise ImportError("setuptools can't be imported *after* distutils
has already been loaded. Please move it earlier in your import
This would at least force you to know that you need to pull setuptools
in early in your code if you have distutils-using code anywhere (even
implicitly, like via weave).
Dumb idea too? (likely...)
> The appropriate fix is to document that weave uses numpy.distutils and
> that if one is going to use both setuptools and numpy.distutils that
> setuptools must be imported first. I believe you have commit access.
Yup, I'll try to add a note to that effect. I can still see this
biting some unsuspecting soul, even if it's documented. It's a very,
very easy trap to fall into.
>> At least that's been my (by now very long running)
>> story.... Here's one hoping that the fork will eventually produce a
>> viable long-term solution to this horrid mess.
> Nope. This is intrinsic to the design of distutils. The only way to
> extend the commands is to subclass. Multiple extensions at the same
> time need to be merged manually. If they are implemented without
> knowledge of the other, it doesn't matter how good or careful the
> authors of each are. In fact, the fork just made things a little
> worse. Now we have to check for both distribute and setuptools.
Worse for now, but I dream it will kickstart activity for a proper
long-term solution, even if that means that someone bites the bullet
of fixing distutils. I know that's a crazy long shot, but you never
know. There *has* to be a better long-term solution to this problem
More information about the Scipy-dev