On Wed, Sep 24, 2008 at 7:38 PM, Phillip J. Eby <pje@telecommunity.com>wrote:

At 01:32 PM 9/24/2008 +0200, Tarek Ziadé wrote:

...

Hi,

I am launching a fork of setuptools. The name is "Distribute". (not definitive) and will be community-driven

This fork will remain 100% compatible with setuptools, and follow closely setuptools evolutions.

Unfortunately, the only way you can remain 100% compatible with code "in the field" is by calling your distribution "setuptools" also, or by having it also install a dummy setuptools egg or at least .egg-info. Otherwise, packages that declare a dependency to a specific setuptools version will cause it to be installed, thereby overwriting your package. There's also setup scripts that use ez_setup, which you could work around for easy_install scenarios with clever enough monkeypatching, but someone directly running a setup script would still break.

If you're going to attempt this, I would consider very carefully how you will address these issues, as it seems to me that it would be very easy for someone to silently hose their system this way, and possibly quite difficult to find out what went wrong or how to fix it.

Yup. I thought of different ways today, but trying to beat the main setuptools package installation is a non sense and will lead to problems. I think we will do like how you did to override distutils. It's OK for us to drop the 'setuptools' dependency in all our packages, and simply tell interested package maintainers to switch "setuptools" to "distribute" in their import line in setup.py files, and have a code base that is similar, besides the fact that it does a smart override of the commands, like you did, and a few other thing I still need to list. The only difference is that it will be run by a community, and I am pretty sure someone that has a bugfix or a feature available in Distribute wouldn't mind changing a simple import line and a dependency in his package and tell people to use it. I won't release the first version of Distribute friday since you have released 0.6c9, so the first release for Distribute will be in one month. A first sprint will probably be organized at the Plone Conference in two weeks on this topic. Best Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

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

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