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

Ned Deily nad at acm.org
Mon Oct 5 13:33:08 CEST 2009

In article <4AC9BEF5.7080204 at taupro.com>, Jeff Rush <jeff at taupro.com> 
> 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 


 Ned Deily,
 nad at acm.org

More information about the Distutils-SIG mailing list