On Thursday 08 October 2009, 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.

-Toshio

----- Forwarded message from Arfrever Frehtes Taifersar Arahesis arfrever.fta@gmail.com -----

Date: Thu, 8 Oct 2009 23:07:13 +0200 From: Arfrever Frehtes Taifersar Arahesis arfrever.fta@gmail.com To: distutils-sig@python.org Subject: Re: [Distutils] Packaging Distribute X-BeenThere: distutils-sig@python.org

2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):

...

On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé ziade.tarek@gmail.com

wrote:

...

The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now

Interesting. Gentoo uses distribute but retains the name 'setuptools'?

It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute.

...

Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository?

We could switch to back to Setuptools only if Setuptools became more maintained than Distribute.

+1 on switch to distribute. One drawback of setuptools is no uninstall. From what I've heard, distribute is more likely to have this sooner.

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]