[Distutils] Annoucing distribute project
ccomb at free.fr
Thu Sep 25 00:09:56 CEST 2008
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,
> not to mention:
> ...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.)
More information about the Distutils-SIG