Distribute, a setuptools fork.
by Tarek Ziadé
That’s enough !
Setuptools is now a big part of our Python development and release infrastructure.
But we have been struggling with the setuptools development process for months around here. The project is run by one single man, who is really busy on other things as well. I am not blaming him, he’s doing a great job. I am just saying that setuptools needs to be more open.
Yesterday, I had, like the week before, some developers complaining about some incompatibility between setuptools and Subversion 1.5.
It is not like it is a hard to fix, and as a matter of fact it is fixed now in the trunk of the project. But not released since quite a long time now. So I have to ask my developers to checkout the trunk on their buildout, and use the ==dev tag elsewhere. I proposed some help to do the release, but my mails were just ignored.
There are also a lot of improvments to do in this tool, so Python gets the distribution tool it deserves.
But having one single person with the commiter rights is not possible on such an important package for the community. It has to be community-driven.
Enough talking, I am launching a setuptools fork, which will be community-driven, and wich will remain 100% compatible with setuptools at this point.
You can react, of follow the reaction on the distutils-SIG I started here : http://mail.python.org/pipermail/distutils-sig/2008-September/010031.html
Maybe my attempt to make such a tool belong to the Python community will fail, I don’t know. Maybe people will not like seeing someone forking like that and will continue to sleep and to unsubsribe themselves from the distutils-SIG.
But at least I am trying something because Python is suffering from a lack of a good, robust distribution tool at this point and there are a lot of people that could contribute if the development process is more open and the maintainer(s) more available and reactive.
I have contributed a bit in distutils in the past year, but the Python core development team has a lack of interest in this part of Python at this time. Thanks to some of the core team members, I could have some patch applied in the trunk, like the multiple servers pypirc. But we won’t be able to create what I would call ‘distutils 2’ in Python itself at this point. And setuptools seems to be the best candidate for a distutils replacement in the future.
As long as the community can work on it of course ! We are the community, we are distributing large application to our customers.
So that’s what “Distribute” is about.
Interesting, easy_install and setuptools getting a little competition, on the same day.
I actually haven’t ever had to learn all that much about the limitations of either, but I expect that I will shortly, so it’s really nice to see these efforts in place.
Good luck, and perhaps at some point I’ll be able to chip in.
Tarek,
This is great news. I agree that the current situation with setuptools is unacceptable, and that something needs to be done. Even if all this fork would do was to make the original setuptools development open up more to outside contributors, it will have done its job.
And, your code is of great quality, so I’m excited that you’re doing this. Having proper dependency handling and all the things that go with it is exceptionally important, especially for where I’m personally coming from (Plone).
…and with Ian’s pyinstall, it’ll be interesting to see where this takes us. 🙂
I see setuptools 0.6c9 was finally released today. Coincidence? I think not 😉
@Alec: thanks for the support
@Alex: thanks for the support and the compliments. You are right, the Plone community is one the biggest consumer of setuptools, and this project should not slow it down. Opening setuptools is the way to go, or Distribute will probably get bigger at some point since its development process will be open.
@Marius: hehe, well this is a great news. I have therefore postponed the first release of Distribute in one month and I am starting to list the bugfix and feature request that we will work on for it. A sprint will be organized at the PloneConf on this topic.
I think it’s been pretty obvious that setuptools development needed to be kickstarted, and I hope that this fork either moves the trunk forward and fades away, or officially becomes the place where that happens.
Either way, it seems like the announcement itself has started some forward momentum, and I’m very glad to see it happening.
[…] to be done. This week has spawned two interesting new projects pyinstall from Ian Bicking, and distribute a potential setuptools fork. Ian’s project looks great with exactly the features that […]