[Python-Dev] Distutils ML wrap-up: setup.cfg new format (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Sep 23 16:04:05 CEST 2009

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% disagreement. 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.

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.

More information about the Python-Dev mailing list