[Distutils] Annoucing distribute project

[Christophe Combelles]

Phillip J. Eby a écrit :
> 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.

The decrease in stability may be significant, indeed but releasing more often 
means the code will be much more tested, then fixed much quicker.

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

I'm not sure about the difference between a dev-tagged egg and an eternal 0.x 
candidate release. Was setuptools 0.6c8 really stable and up-to-date?

> 
> 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.)
> 
> 
>