Re: [Distutils] Annoucing distribute project
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.
On Wed, Sep 24, 2008 at 7:38 PM, Phillip J. Eby
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/
Tarek Ziadé a écrit :
Hi,
I am launching a fork of setuptools. The name is "Distribute".
What about "distributing"? as with threading, processing, logging, ... string (mmh... no. Not string ;)
(not definitive) and will be community-driven
Ah! this point is much more important than the name, that sounds good.
This fork will remain 100% compatible with setuptools, and follow closely setuptools evolutions.
The best thing would be to have this kind of tool eventually integrated into Python!
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
0.6c9 was urgently needed (thanks for the release...) because of svn 1.5 incompatibility, but there are a LOT of other improvements that are already wanted, such as support for other (d)vcs, an easy_uninstall, etc... I sincerely hope that things will speed-up with this fork. I'm volunteering to help on this effort. Christophe
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 http://www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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.)
On Wed, Sep 24, 2008 at 11:34 PM, Phillip J. Eby
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.)
The point is that the stability you are claiming means that the whole community depends on your actions. The fact that you were busy lately made things even slower. That is my whole point. Even if you set up a snapshot facility, the only person that is able to make changes in setuptools is you and only you. Distribute will be driven by more people, and its trunk will be more unstable for sure. But it think we can do some valuable test-driven work all together, and our releases can be quite good. So I'll make it clear to our users: it will be a project with stable releases, and unstable features in branches, and a trunk to merge everything, like all the open source project out there. Best Regards Tarek
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
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.)
Phillip J. Eby wrote:
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,
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).
I agree, in that we must not add features without careful thought as to their impact and cross-platform support. Python is a conservative community and we've seen value in the role of an gatekeeper who sees the bigger picture, as Guido and others for other projects. Of course, a gatekeeper who is too-strict isn't good either - there must be balance. But to the distribute project, because of the nature of standardizing package technology, running this is a huge responsibility. Please do not start adding all features asked for without considering their tradeoffs. One issue with something like setuptools is that packaging APIs get immortalized in setup.py files that are not easy to go back and change, so the APIs must carry heavy backward compatibility baggage. You may want to consider using PEPs as a basis for discussing change requests. They're not just for the core Python language. -Jeff
participants (4)
-
Christophe Combelles -
Jeff Rush -
Phillip J. Eby -
Tarek Ziadé