Re: [Numpy-discussion] Setuptools leftover junk

[Fernando P. <fpe...@gm...>]

On 6/28/06, David M. Cooke <co...@ph...> wrote:
> On Wed, 28 Jun 2006 13:18:35 -0600
> "Fernando Perez" <fpe...@gm...> wrote:
>
> > On 6/28/06, David M. Cooke <co...@ph...> wrote:
> >
> > > Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
> > > with an import of setuptools (it's based on the one used in matplotlib).
> > >
> > > easy_install still works, also.
> >
> > You beat me to it :)
> >
> > However, your patch has slightly different semantics from mine: if
> > bdist_egg fails to import, the rest of setuptools is still used.  I
> > don't know if that's safe.  My patch would consider /any/ failure in
> > the setuptools imports as a complete setuptools failure, and revert
> > out to basic distutils.
>
> Note that your patch will still import setuptools if the import of bdist_egg
> fails. And you can't get around that by putting the bdist_egg import first,
> as that imports setuptools first.

Well, but that's still done after the 'if "setuptools" in sys.modules'
check, just like yours.  The only difference is that my patch treats a
later failure as a complete failure, and reverts out to old_setup
being pulled out of plain distutils.

> (I think bdist_egg was added sometime after 0.5; if your version of
> setuptools is *that* old, you'd be better off not having it installed.)

Then it's probably fine to leave it either way, as /in practice/ the
two approaches will produce the same results.

> The use of setuptools by numpy.distutils is in two forms: explicitly
> (controlled by this patch of code), and implicitly (because setuptools goes
> and patches distutils). Disabling the explicit use won't actually fix your
> problem with the 'install' command leaving .egg_info directories (which,
> incidentally, are pretty small), as that's done by the implicit behaviour.

It's not their size that matters, it's just that I don't like tools
littering around with stuff I didn't ask for.  Yes, I like my code
directories tidy ;)

> [Really, distutils sucks. I think (besides refactoring) it needs it's API
> documented better, or least good conventions on where to hook into.
> setuptools and numpy.distutils do their best, but there's only so much you
> can do before everything goes fragile and breaks in unexpected ways.]

I do hate distutils, having fought it for a long time.  Its piss-poor
dependency checking is one of its /many/ annoyances.  For a package
with as long a compile time as scipy, it really sucks not to be able
to just modify random source files and trust that it will really
recompile what's needed (no more, no less).

Anyway, thanks for heeding this one.  Hopefully one day somebody will
do the (painful) work of replacing distutils with something that
actually works (perhaps using scons for the build engine...)  Until
then, we'll trod along with massively unnecessary rebuilds :)

Cheers,

f