[Distutils] Distribute and zc.buildout + bootstraping file names + release/branches roadmap
ziade.tarek at gmail.com
Tue Aug 4 22:50:26 CEST 2009
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
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
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 ?
Tarek Ziadé | http://ziade.org
More information about the Distutils-SIG