[SciPy-dev] weave.inline broken by setuptools?

Robert Kern robert.kern@gmail....
Thu Sep 25 23:57:24 CDT 2008

On Thu, Sep 25, 2008 at 23:47, Fernando Perez <fperez.net@gmail.com> wrote:
> On Thu, Sep 25, 2008 at 9:34 PM, Robert Kern <robert.kern@gmail.com> 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,

*bzzrt!* No. That's not the problem. It's dangerous to pull in
setuptools after *numpy.distutils*. It's the particular combination of
those two that needs to be managed carefully. Importing distutils
before setuptools is harmless.

> 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
> chain.")
> 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...)

Probably. One could equally make the same case for any extension to
distutils, like numpy.distutils. If they all raised such an error,
*none* of them could be combined with each other.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco

More information about the Scipy-dev mailing list