atom feed5 messages in com.redhat.fedora-python-devel-listdistribute vs setuptools
FromSent OnAttachments
Toshio KuratomiOct 8, 2009 2:55 pm 
Neal BeckerOct 9, 2009 4:34 am 
Gael VaroquauxOct 11, 2009 10:17 am 
David MalcolmOct 16, 2009 3:10 pm 
Toshio KuratomiOct 31, 2009 10:05 am 
Subject:distribute vs setuptools
From:Toshio Kuratomi (a.ba@gmail.com)
Date:Oct 8, 2009 2:55:10 pm
List:com.redhat.fedora-python-devel-list

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
<arfr@gmail.com> -----

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

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

On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziad@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.

-- Arfrever Frehtes Taifersar Arahesis

_______________________________________________ Distutils-SIG maillist - Dist@python.org http://mail.python.org/mailman/listinfo/distutils-sig

----- End forwarded message -----