[Distutils] Packaging situation + mailing list rules

P.J. Eby pje at telecommunity.com
Fri Jul 2 19:52:07 CEST 2010

At 04:13 PM 7/2/2010 +0200, Tarek Ziadé wrote:
>On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > Isn't it interesting how these rules prohibit open disagreement 
> or criticism
> > (or even discussion!) of distribute and related matters, but *not*
> > setuptools?
>There's a huge gap between criticism + discussion, and the habitual flame
>of distribute vs setuptools. I think you know what I mean.

Since, as far as I can tell, David's are the first negative comments 
I've seen regarding distribute, the only "habitual" flame I'm aware 
of would be people spreading falsehoods about setuptools.

I personally don't consider mere criticism of setuptools' or 
distribute's code or policies to be flaming.

> > On a separate note, I'm curious why discussion of Distutils2 development is
> > not in a formal Python SIG, such as the Distutils-SIG.
>To avoid such threads and flames.

Vigorous discussion is a normal part of life in a Python SIG, or any 
standards-development process.  Lots of people have said plenty of 
mean and nasty things about setuptools here (and to a lesser extent, 
people said them about WSGI when I started that effort), but I have 
never called for them to be silenced.

The only thing I object to is people making statements that they know 
(or should know) are false, or to people speaking with flagrant 
disregard for the truth in an apparent effort to score political points.

There is *huge* difference to me between, "Hey PJ, I hate setuptools 
and it sucks!" and "Nobody should use setuptools because it is unmaintained."

Regarding the first one, I say, "Sorry to hear that, good luck to you 
with your future endeavors."  The second one, however, is FUD and an 
unnecessary smear tactic.

And I find it strange that many distribute supporters seem to prefer 
this approach over highlighting distribute's *actual* distinctions 
from setuptools, such as (not a complete list):

* It has more tests
* It runs on Python 3
* It supports 2.6+ "user" directories
* It is released more frequently
* We review patches more quickly
* It's available in Mercurial, so you can more easily track local 
changes and participate in development

(And even *I* agree that these are all benefits for many people.)

However, perhaps it's a reflection of the fact that these benefits 
are NOT universally salient -- for many people, not one of these 
improvements is important enough to merit switching.  So, if someone 
has other reasons than *user benefit* for wanting everyone else to 
switch, then perhaps they are forced to resort to FUD to motivate 
people to switch.

And THAT is what I find distasteful.  If you want people to switch 
because it is *actually* better for them, then more power to 
you.  However, trying to persuade people to switch for *political* 
reasons -- reasons that will not provide any actual *benefit* to the 
switchers -- that's just disgusting.

If people want to get creative in their presentations of the truth, 
please stick to exaggerating the advantages of distribute, rather 
than exaggerating the disadvantages of setuptools.  The former is to 
be expected, the latter is unnecessary nastiness...  especially since 
I bend over backwards *not* to say bad things about distribute, even 
when I'm more or less forced to comment on technical differences 
between the two.

Indeed, I take especial care to treat them as mere stylistic 
differences, even when I think that distribute's choices will 
actually lead to problems for a given user's use case, simply because 
I don't want to deal with the flaming that ensues any time I say 
something that can remotely be construed as a criticism of 
distribute.  (Consider the brouhaha that erupted the time I simply 
stated that if people wanted to upgrade to the latest setuptools, 
they would need to uninstall distribute first -- which is a mere 
technical fact caused by the way distribute operates!)

More information about the Distutils-SIG mailing list