pje at telecommunity
Oct 7, 2009, 11:57 AM
Post #18 of 26
(2443 views)
Permalink
|
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
>scott [at] scottdial
>scodial [at] cs
>_______________________________________________
>Python-Dev mailing list
>Python-Dev [at] python
>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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
smime.p7s
1
