[Python-Dev] Distutils ML wrap-up: setup.cfg new format
ziade.tarek at gmail.com
Wed Sep 23 19:00:20 CEST 2009
On Wed, Sep 23, 2009 at 4:04 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 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.
While it's great to have Philipp being part of our distutils design
for his experience, I am not concerned of not having him in this "internal
consensus" since Setuptools is not maintained anymore.
He said some months ago, he would work on a brand new setuptools
version with zero
dependency to distutils. But it's still vaporware (from his own
words), and the previous version is unmaintained for a year, so it was
The Distribute (setuptools fork), which is likely to be the first and
only public packaging system
on the top of distutils working under Python 3 (the trunk is
py3k-ready and should be released
in a few days), is pretty active, and none of his contributor raised
against the proposal.
But you are right about the need of making sure every package management
project is involved. We should make sure that Enthought,
which has its own package management system, is part of that consensus.
Also, I am more concerned of not having enough end users involved in
End users would be: any python developer that needs
to package his code, or any os packager that needs to package a python
for his system. But those are hard to get involved.
> 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.
Please note that the controversy that popped in python-dev didn't popped in
distutils-SIG after I clearly stated that I was going to send a
summary in python-dev,
(which I did four days after). No one commented on it then.
Next time I'll wait a week and I will also send the summary as you suggested,
to make sure everyone sees the message, not hidden inside a big thread.
But I doubt this will cut all further controversy once it's in
being controversial in Python-dev doesn't have the same impact for the writer
and the readers.
More information about the Python-Dev