Hi, I am working on the last bits to be able to release 0.6 1/ Distribute and zc.buildout I started to work on the last bootstraping problem we have : make sure zc.buildout users can use it. I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that is a patched version of zc.buildout's bootstrap.py. This version makes sure Distribute is installed and activated in a buildout environment. It's also in the repo, in the buildout directory. Again, this requires a lot of real-world testing before we can ship 0.6. I've started to test various combinations on my side, but as I did for the previous bootstraping script, I wouldn't mind having some feedback of various people on this. If you use zc.buildout, you can try it by replacing the bootstrap.py file that comes with your buildout with the one I work on, then a/ add "distribute" to the required eggs in your buildout cfg file b/ run or re-run the bootstrap: $ wget http://nightly.ziade.org/bootstrap.py $ python bootstrap.py If it worked, your buildout should build and work just fine, and the scripts located in bin/ should have their sys.path augmented with the distribute egg. Last, the setuptools egg is faked and you wil notice that it's empty. This has to be done so zc.buildout and any software out there that has a hardcoded dependency on setuptools thinks it's present. This is reversible, by running the original bootstrap and removing the egg dependency added in the cfg file. Please let me know if you try and get in any trouble. I was able to run a plone buildout on my side with no problems. 2/ bootstraping file names To avoid any confusion, I've changed distribute's bootstrap file name. So we will have: - ez_setup.py = setuptools bootstrap file - bootstraping.py = distribute bootstrap file - bootstrap.py = zc.buildout bootstrap file If you think "bootstraping" is a silly name, or have a better proposition, please let me know. 3/ release/branches roadmap I'll probably release 0.6 before the end of this week and I expect pushing a 0.6.1 one if we find big issues with the bootstraping we didn't see before, when the release goes live. As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance and we will be able to work on 0.7 on the default branch, including the Python 3 work. Other Py3k remaning branches will be removed/stripped. I think this is a simpler approach. The 0.7 release will get ridd of the bootstraps script and create several distributions, so a massive refactoring is expected. I don't know if this will make it harder for py3k work, Lennart, Ronald ? Cheers Tarek -- Tarek Ziadé | http://ziade.org