[Python-Dev] Distutils ML wrap-up: setup.cfg new format

[Stephen J. Turnbull]

Tarek Ziadé writes:
 > On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
 > > At the very least, that would have kept this discussion on Distutils-
 > > SIG, and Chris couldn't be accused of trying to make an end run around
 > > that process.  I suggest that posting progress reports to Python-Dev
 > > is a good idea (attracting attention and maybe participation to the
 > > process), but making one an opportunity to test the degree of internal
 > > consensus (or lack of it) on Distutils-SIG by posting there first is
 > > an even better one.
 > 
 > Please define what "internal consensus on Distutils-SIG" means.

Definition is your job, as chairman/dictator.

I did offer a concrete criterion for an individual's participation in
a "internal consensus": that you expect that they will adopt the new
features of distutils as a foundation for their own distribution
systems, or at least not implement and promote an alternative.

As for who needs to be included, if the author of setuptools isn't
part of the internal consensus (on that, I'm just guessing from the
fact that he went off to "start a new thread"), I think you should be
concerned.  He's already implemented and promoted an alternative in
the past, so he doesn't even have to do any implementation.  Just keep
on using and promoting his preferred tools and formats.

A third point is that you can have a consensus on "agreeing to
disagree".  But it's unlikely that you will have 100% *dis*agreement.
If you can get a consensus that on certain points certain people are
simply not going to change their minds, it's often possible to move
past that to work on things that you can agree on.  (And if some
people are unwilling to even admit that, it's usually clear to
absolutely everybody else.)

 > distutils, don't you agree that it's impossible in this context to
 > get a 100% consensus ?

Depends on how you define "100% consensus".  If you mean 100% of
people agree on 100% of the proposal, of course not.  But there may be
40% of the proposal you can get 90% of the people to agree on, and
maybe 90% of the proposal is acceptable to 40% of the people.  (That
would be pretty good in this case, but this community regularly
manages to come close to that, so there's some hope.)

If you can get the setuptools and buildout people to agree to use some
parts of "new distutils", that's a form of consensus, and definite
progress.

 > and that I need to take some decisions to move distutils on ?

I don't know; a better distribution system is not something I need as
a user or a developer.  What worries me is that a simple progress
report caused dissension to spill over onto the Python-Dev list.  That
is relatively rare in this community.  And people like Brett think
it's important that some progress be made on distutils, so I'd like to
see it done as quickly as possible -- but no quicker.<wink>

 > Especially for this topic. If you take the time to read everything
 > you'll see that there were no real alternative design proposed, and
 > that I am just working out the details because I maintain and code
 > distutils.

Well, from the behavior of Philip and Chris, it seems that their
position is that there was insufficient time to put forward an
alternative design before the summary was posted to Python-Dev.  *I
don't care whether its true or not*, it's your job as chairman/
dictator to decide that, and we shouldn't discuss it here.  But merely
leaving the *impression* is damaging, and I suggested a simple
procedure (posting the summary to your mailing list and requesting
comments) that would very likely improve the summary, and also be
likely to keep unnecessary controversy off Python-Dev.