I'm not really sure how to reply to your email, since it seems to be
based on several major misunderstandings. So, just a few key points:
* Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
* Distribute 0.7 is vaporware, very much like setuptools 0.7
* Packages using distribute 0.6.x still say "import setuptools"
* Suggesting that the stdlib include the *other guys' code* is not
"political bickering" - it's a positive proposal for moving forward
that eliminates both technical and political obstacles. If you
thought I was being sarcastic or ironic, you are mistaken.
At 01:22 PM 10/7/2009 -0400, Scott Dial wrote:
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.
</flame>
--
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com