[Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

[Ned Deily]

In article <4AC9BEF5.7080204 at taupro.com>, Jeff Rush <jeff at taupro.com> 
wrote:
> Lennart Regebro wrote:
> > 2009/10/3 Ned Deily <nad at acm.org>:
> >> This is not a good experience for users.  Unless I'm missing something
> >> (and I hope I am), this issue really can't be hand-waved away.
> > 
> > It's unfortunate that this comes in a minor release.
> Very unfortunate, as in, it should NOT have happened.  And *especially*
> without any announcement on python.org or mention on the
> python-committers list of something this major.
> > But at the same
> > time we can hardly avoid fixing bugs just because setuptools isn't
> > getting updated at the moment. It's a lose-lose situation.
> Setuptools is hardly a minor software tool.  Considering that setuptools
> is a major focus and key technology of this group, those making changes
> to distutils should have tested against setuptools and devised a
> solution providing backward compatibility, along with deprecation
> warnings.  Lennart and Tarek, I know you at least are familiar with this
> valuable practice in Zope for years.
> 
> At the least, those making changes to Distutils should, after testing
> against Setuptools, widely announced this was coming.  It does not
> reflect positively on the Distribute team and even hints of
> under-the-table intentionality in forcing the community to abandon use
> of setuptools.  Distribute should win because of superior technology not
> forced migration.
> 
> > As I see it this will speed up adaptation of Distribute. Word will
> > spread. It's not ideal, but then it's not a perfect world.
> 
> Distribute is very new and there are many folk who will not be adopting
> it until it has been out for quite some time.  It is a fact of the
> conservative nature of some development teams.  If setuptools were an
> optional, little-used technology in Python it would not be a big deal
> but it isn't.  It is not appropriate to -force- users to adopt a
> particular branch of a fork, except perhaps in the move from Python 2.x
> to 3.x where major changes are anticipated and there was no setuptools
> for 3.x anyway.

Just another data point: the MacPorts distrbution has just upgraded 
their python26 to 2.6.3 and now a number of their py26 packages can't be 
installed because they use setuptools (or depend on another package that 
uses setuptools) to build C extensions and those fail due to the change 
in distutils: among others, ipython, numpy, pyobjc2, twisted.  Until the 
MacPorts folks recognize and push out a fix, using the setuptools 
easy_install to install distribute works - if you know the trick.

> Considering that 2.6.3 is messed up in other ways, like displaying the
> SVN rc1 tag and a broken logging module, and probably will be
> re-released at 2.6.4 very shortly, perhaps we can get this -at least-
> into the Python docs and maybe introduce backward compatible hooks into
> distutils to support setuptools.

I've opened an issue of the main Python issue tracker outlining the 
problem, primarily for the benefit of affected users who search the 
tracker:

   http://bugs.python.org/issue7064

-- 
 Ned Deily,
 nad at acm.org