distribute vs setuptools

[David Malcolm]

On Thu, 2009-10-08 at 14:55 -0700, Toshio Kuratomi wrote:
> So I just read this piece of news on the distutils-sig list.  Here's a
> summary/background.
> 
> setuptools has become increasingly popular as a method of making python
> modules easier to package (by upstream), managing plugins, and getting
> version requirements right.  However, the setuptools author has been
> somewhat lackadaisical about maintaining the code, integrating bugfixes,
> etc.  Since the setuptools author hasn't wanted to pass the torch on to
> someone else, the project has forked.  Distribute-0.6 is the compatible fork
> with multiple maintainers who are interested in preserving setuptools
> compatibility in the 0.6 branch and making real (but API changing)
> improvements in the 0.7 branch.
> 
> Due to the non-maintenance of setuptools, some other Linux distros have
> started shipping distribute-0.6 as their setuptools module.  Their plan is to
> ship distribute-0.6 as setuptools and distribute-0.7 as distribute.  By
> doing this, the consumers of setuptools don't have to change their package
> (all the import statements) to use distribute instead of setuptools.  If
> they didn't do this, the packages would need to be patched to use distribute
> instead of setuptools.
> 
> The benefit of this is that they get a maintained piece of code with an
> upstream that is responsive to bug reports, patches, and takes distribution
> problems into consideration (even if they can't always do something about
> them in the 0.6 codebase).  The downsides are that the setuptools upstream
> is alive even if it isn't thriving and the setuptools maintainer could throw
> a monkey into the works by releasing API breaking changes when he does a new
> setuptools release.
> 
> Since I'm the current setuptools maintainer and have had issues trying to
> get bugs fixed in upstream setuptools before, I'm inclined to do this as
> well but the drawbacks are nothing to ignore.  So what do other people think
> of our doing this as well?  If we don't do this, an alternative might be to
> plan on packaging distribute0.6 and distribute0.7 parallel installable.
> Then we can port packages to use distribute instead of setuptools when its
> available and submit those patches to upstream projects.

You've got more knowledge in this area, so I'd tend to defer to your
judgement here.

One area that excites me about Distribute is support for Python 3 e.g.
the idea of being able to run 2to3 as part of the build process.  Not
sure how sane that last one is, but it may be that we need Distribute in
order to build out a python 3 stack in Fedora.  Haven't checked the
details yet though.

[snip]