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