<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Sep 24, 2008 at 7:38 PM, Phillip J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>At 01:32 PM 9/24/2008 +0200, Tarek Ziadé wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I am launching a fork of setuptools. The name is "Distribute". (not definitive) and will be community-driven<br>
<br>
This fork will remain 100% compatible with setuptools, and follow closely setuptools evolutions.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.</blockquote>
<div><br>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.<br><br>I think we will do like how you did to override distutils. <br>
<br>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. <br>
<br>
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.<br>
<br>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.<br>
<br>Best Regards<br></div></div>Tarek<br><br clear="all"><br>-- <br>Tarek Ziadé | Association AfPy | <a href="http://www.afpy.org" target="_blank">www.afpy.org</a><br>Blog FR | <a href="http://programmation-python.org" target="_blank">http://programmation-python.org</a><br>
Blog EN | <a href="http://tarekziade.wordpress.com/" target="_blank">http://tarekziade.wordpress.com/</a><br>
</div>