[Python-Dev] a new setuptools release?

Scott Dial scott+python-dev at scottdial.com
Wed Oct 7 19:22:12 CEST 2009

P.J. Eby wrote:
> At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
>> suggest nobody hold their breath waiting for setuptools 0.7.
> I've never suggested or implied otherwise.
> But, if you like Distribute so much, why not just add it directly to the
> stdlib?  ;-)
> There are many wins to be had from such a move, not the least of which
> is that it allows something to go into the stdlib that isn't
> (branding-wise) associated with me or setuptools, and lets it become
> owned/supported by an even wider community.

I think the biggest problem here is that the brand ("setuptools") is so
ingrained in the world that someone releasing something
setuptools-but-not-setuptools ("Distribute") is at a serious
disadvantage. Your insistence on retaining the name "setuptools" for
yourself and your vapor-ware only harms the community at-large.

Even experienced developers are unaware of Distribute's existence.. I
was entirely unaware until yourself and PJE got in a bickering exchange
on Python-Dev this past month. The extremely high visibility of your
stale package compared to their non-stale package is quite unfortunate.
You are free to say, "that is their problem," but you are not free to
say, "it is not my fault."

> AFAIK, the only reason they've had multiple releases of it is to
> address the issues with its hijacking of setuptools; in a stdlib
> version all that stuff could be dropped.  Otherwise, it'd already be
> "mature".

IOW, you acknowledge that your own position and requiring them to
tolerate the parallel existence (in the world) of setuptools harms
Distribute. I fail to see how this relates to being in the stdlib. As
long as it is not called "setuptools" and packages in the world say
"import setuptools", then there are conflicts they will be forced to
managed. And moreover, as long as a stale, perhaps buggy version of
setuptools is the compatibility model they must emulate, they will have
a hard time coexisting.

> Less political bickering, and the some of the technical results I
> hoped for all along are achieved.  Yay, open source.

And yet, political bickering seems to be all you are good for in this case.


Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

More information about the Python-Dev mailing list