Tarek Ziadé wrote:
On Wed, Sep 23, 2009 at 4:04 PM, Stephen J. Turnbull <step...@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
discussions,
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
forked.
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.
Note that Activestate also have a fledgling package management system
for Python (unreleased yet I *believe*) so it is probably worth reaching
out to them as well.
Also, I am more concerned of not having enough end users involved in
that process.
End users would be: any python developer that needs
to package his code, or any os packager that needs to package a python
distribution
for his system. But those are hard to get involved.
Perhaps post your summaries on your blog as well (which is aggregated on
Planet Python right?) - including a description of the problem it aims
to solve and how it will be used.
You'll *mostly* be reaching the same set of people, but at least it
spreads the net a bit wider.
Michael
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
Pyton-dev, because
being controversial in Python-dev doesn't have the same impact for the writer
and the readers.
Tarek
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
