[Distutils] Annoucing distribute project

[Phillip J. Eby]

At 10:54 PM 9/24/2008 +0200, Christophe Combelles wrote:
>there are a LOT of other improvements that are already wanted, such 
>as support for other (d)vcs,

See:

   http://pypi.python.org/pypi?:action=browse&c=524

and:

   http://pypi.python.org/pypi?%3Aaction=search&term=setuptools&submit=search

not to mention:

   http://bugs.python.org/setuptools/issue42

...especially my comments on what the existing patch still needs in 
order to be accepted.


>an easy_uninstall, etc...

http://bugs.python.org/setuptools/issue21 is tracking this, but I 
have not reviewed the submitted patch in any detail.  It would be 
much better to have a design proposal to review first.

Note, by the way, that the reason most of the items listed as 
"feature" or "wish" on the tracker are in those statuses are because 
nobody has proposed a design for critique.  Usually, it's just wishes 
for magic ponies (e.g. uninstall, post-install hooks, etc.) without 
any discussion of how to deal with the edge cases, interactions, or 
other negative consequences of said features.  (magic pony manure?)


>  I sincerely hope that things will speed-up with this fork.

I imagine they might speed up, but likely at the cost of 
stability.  If anybody knew enough to be able to add these features 
in a safe way, then they knew enough to be able to contribute patches 
to setuptools (after first proposing how they would handle all the 
nasty edge cases).

In principle, I have no problems with a fork.  In practice, 
however,  I would expect significant new features (e.g. uninstall) to 
be accompanied by a significant decrease in stability.

In other words, I don't recommend mixing fork goals.  If the goal is 
merely to have more-frequent releases of setuptools, it would be 
better to have a snapshot facility for same, and release dev-tagged 
eggs.  Conversely, if the goal is to prototype new features, then it 
doesn't make a lot of sense to advertise it as a stable or up-to-date 
setuptools.

So, my personal hope is that the persons doing the fork will make it 
clear to their users which it is: unstable feature prototype, or 
simple release snapshots?  (Where the latter could just as easily be 
automated.)