[Python-Dev] a new setuptools release? (original) (raw)

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