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]