[Distutils] Buildout release news

Maurits van Rees m.van.rees at zestsoftware.nl
Tue Aug 24 16:29:28 CEST 2010


Op 24-08-10 13:33, Reinout van Rees schreef:
> On 08/20/2010 05:22 PM, Gary Poster wrote:
>> I intend to release zc.buildout 1.5.0 Monday, August 23.
>
> I used http://pypi.python.org/pypi/osc.recipe.sysegg/ to reliably grab
> specific system python packages (PIL, matplotlib, etc). That one is
> broken with 1.5.0, as it cannot find PIL and friends anymore.
>
> Using the
> http://svn.zope.org/repos/main/zc.buildout/branches/1.4/bootstrap/bootstrap.py
> helps getting everything working (at least temporary).
>
> osc.recipe.sysegg's problem is that a pkg_resources.require(egg) call
> doesn't find any of the system eggs anymore. Am I correct that that's
> one of buildout's changes? That the recipes are really totally isolated?
>
>
> One thing I don't understand is why all my buildouts suddenly started
> failing: I've pinned zc.buildout in all my buildouts. Did the
> couple-months-old bootstrap.py (so: no svn:externals!) somehow manage to
> pull in a new buildout despite the version pin?
>
> I had to go through a couple of projects to grab the 1.4 bootstrap.

If I understand correctly, one of the new things that the new 
bootstrap.py does, is to actually look at the version pinning for 
zc.buildout (and probably setuptools/distribute) in buildout.cfg and use 
that for creating the initial bin/buildout script.  So if you are using 
an old bootstrap.py, I would indeed expect that you get the latest 
zc.buildout version.

Errr... no, I have now tried it with a few different bootstrap.py 
versions, and after 'python2.4 bootstrap.py' I always end up with the 
zc.buildout that is pinned in the versions.  That is not how I remember 
it, though this suits me fine. :-)  Maybe there is a difference here 
between using distribute (like I do) or setuptools.˘


What I *do* see is that when you start with zc.buildout 1.5.0, then 
change the pin to 1.4.3 and rerun the buildout, this fails when you are 
using a buildout extension.  The other way around (first 1.4.3, then 
change it to 1.5.0) works fine.  I tried it with buildout-versions and 
with mr.developer as extensions, both having the same result.  For 
example, start with this, and any bootstrap.py:

===================================================
[buildout]
extensions = buildout-versions
buildout_versions_file = buildout.cfg
parts = pep8
versions = versions

[pep8]
recipe = zc.recipe.egg
eggs = pep8

[versions]
buildout-versions = 1.3
distribute = 0.6.14
pep8 = 0.5.0
zc.buildout = 1.5.0
zc.recipe.egg = 1.2.2
===================================================

Note that I pinned zc.recipe.egg to 1.2.2 as 1.3.2 conflicts with 
zc.buildout 1.4.3, which I want to try next.

Run python2.4 bootstrap.py (probably same effect with python2.anything) 
and then bin/buildout.  Works fine.  Now change the zc.buildout pin to 
1.4.3 and rerun bin/buildout:

$ bin/buildout
While:
   Installing.
   Loading extensions.
Error: There is a version conflict.
We already have: zc.buildout 1.5.0

With more debugging:

$ bin/buildout -vvvvvvvvvvvvvvvvvvvvD
Installing 'buildout-versions'.
We have the distribution that satisfies 'buildout-versions==1.3'.
While:
   Installing.
   Loading extensions.
Traceback (most recent call last):
   File ".../zc.buildout-1.5.0-py2.4.egg/zc/buildout/buildout.py", line 
1784, in main
   File ".../zc.buildout-1.5.0-py2.4.egg/zc/buildout/buildout.py", line 
410, in install
   File ".../zc.buildout-1.5.0-py2.4.egg/zc/buildout/buildout.py", line 
960, in _load_extensions
   File ".../zc.buildout-1.5.0-py2.4.egg/zc/buildout/easy_install.py", 
line 1085, in install
   File ".../zc.buildout-1.5.0-py2.4.egg/zc/buildout/easy_install.py", 
line 942, in install
VersionConflict: There is a version conflict.
We already have: zc.buildout 1.5.0
Starting pdb:
  > 
.../zc.buildout-1.5.0-py2.4.egg/zc/buildout/easy_install.py(942)install()
(Pdb) a
self = <zc.buildout.easy_install.Installer instance at 0x101e1e320>
specs = ['buildout-versions']
working_set = <pkg_resources.WorkingSet object at 0x10040e810>


The workaround is of course to remove bin/buildout, do python2.4 
bootstrap.py and run bin/buildout again.  So probably no big deal, but a 
bit unexpected anyway.

BTW, this is on MacOSX 10.6.4, with a python compiled using this 
buildout: http://svn.plone.org/svn/collective/buildout/python
I am normally using virtualenv created by this python, with a few more 
modules installed, but I tried with a fresh virtualenv and with using 
the python executable directly as well, with the same results.


Anyway, I have not seen things go really wrong yet today, and my 
buildout-using colleagues have not screamed either, so the troubles of 
the previous beta seem to have been avoided.  Thanks for your hard work, 
Gary!



-- 
Maurits van Rees
Programmer, Zest Software



More information about the Distutils-SIG mailing list