Creating a single-source build environment with zc.buildout that works for both Python 2 and 3 is a bit of a hassle. This blog post shows how to do it for a minimal demo project.
During the sprints at PyCon DE 2012, we tried to make the upcoming 1.0 release of the nagiosplugin library compatible with both Python 2.7 and Python 3.2. Going for a single code base (without preprocessing steps like 3to2) was no too hard. The only thing left was a single-source zc.buildout setup suited for both Python 2.7 and 3.2. It worked out at last, but currently it needs two buildout configurations. This is a little bit kludgy. I hope that things will improve in the near future so that a single-source build environment with zc.buildout will be possible.
In the following, I will demonstrate the steps with a simple demo project called MultiVersion. It contains nothing more than a single class that is supposed to run under both Python 2 and 3. There is also a unit test to verify that the code works. We use zope.testrunner to run the unit tests. The code’s functionality is irrelevant for the examples, so I left it out. You can download the full source if you are interested.
1. Use a recent enough virtualenv
Older versions of virtualenv are generally not suited since they ship with obsolete releases of distribute and pip. Check if the virtualenv included in your GNU/Linux distribution is too old. Anything below 1.8 reduces the chance of success, so better install a current virtualenv locally then. Likewise, our bootstrap.py must be recent enough to support both Python 2 and 3. The standard bootstrap.py from python-distribute.org does currently not work with Python 3.
Now we are ready to create a virtualenv in a fresh source checkout.
Python 3.2:
$ virtualenv -p python3.2 . Running virtualenv with interpreter /usr/bin/python3.2 New python executable in ./bin/python3.2 Installing distribute.....done. Installing pip.....done.
Python 2.7:
$ virtualenv -p python2.7 . Running virtualenv with interpreter /usr/bin/python2.7 New python executable in ./bin/python2.7 Not overwriting existing python script ./bin/python (you must use ./bin/python2.7) Installing setuptools.....done. Installing pip.....done.
2. Running buildout with Python 3.2
I will discuss the steps for Python 3.2 first, since main development will concentrate on newer Python versions. After that, I will describe the necessary steps to make the build environment backward compatible.
To run zc.buildout, we need a buildout.cfg file. I prefer to pin package versions in all projects to ensure reliable builds. As of writing this blog post, there is just an alpha release of zc.buildout that supports Python 3.2. Unfortunately, this version of zc.buildout supports Python 3.2 only, so don’t try this with Python 3.3.
My basic buildout.cfg looks like this:
[buildout]
allow-picked-versions = false
develop = .
newest = false
package = multiversion
parts = multiversion test
versions = versions
[versions]
distribute = 0.6.28
z3c.recipe.scripts = 1.0.1
zc.buildout = 2.0.0a2
zc.recipe.egg = 2.0.0a2
zc.recipe.testrunner = 1.4.0
zope.exceptions = 4.0.1
zope.interface = 4.0.1
zope.testrunner = 4.0.4
[multiversion]
recipe = zc.recipe.egg
eggs = ${buildout:package}
interpreter = py
[test]
recipe = zc.recipe.testrunner
eggs = ${buildout:package}
defaults = ['--auto-color']
In my experience, it is best to pin distutils to exactly the same version that is included in virtualenv’s support files. While differing versions are possible, they may trigger hard to find bugs since it is not always clear which version is used is which step.
I use the Python interpreter from my virtualenv’s bin directory while creating the buildout executable. This saves me from using activate/deactivate scripts which are slightly cumbersome in my opinion.
$ bin/python3.2 bootstrap.py Creating directory 'blog-python-2-3/parts'. Creating directory 'blog-python-2-3/develop-eggs'. Generated script 'blog-python-2-3/bin/buildout'. $ bin/buildout Develop: 'blog-python-2-3/.' Installing multiversion. Generated interpreter 'blog-python-2-3/bin/py'. Installing test. Generated script 'blog-python-2-3/bin/test'.
Now we have a working build for Python 3.2:
$ bin/test Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Ran 1 tests with 0 failures and 0 errors in 0.002 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.
3. Running buildout with Python 2.7
Unfortunately, the current zc.buildout alpha release does not work with anything except Python 3.2. Running bootstrap.py fails:
$ bin/python2.7 bootstrap.py Getting distribution for 'zc.buildout==2.0.0a2'. While: Bootstrapping. Getting distribution for 'zc.buildout==2.0.0a2'. Error: Couldn't find a distribution for 'zc.buildout==2.0.0a2'.
There is no single zc.buildout distribution that fits both Python 2.7 and 3.2. To get around this, I need to create a special-case buildout.cfg that changes version pinnings for incompatible packages. Besides zc.buildout, zc.recipe.egg needs different versions for Python 2.7 and 3.2 as well.
I create buildout-2.x.cfg (slightly grumbling):
[buildout] extends = buildout.cfg [versions] zc.buildout = 1.6.3 zc.recipe.egg = 1.3.2
This one does the job when used with both bootstrap and buildout:
$ bin/python2.7 bootstrap.py -c buildout-2.x.cfg Generated script 'blog-python-2-3/bin/buildout'. $ bin/buildout -c buildout-2.x.cfg Develop: 'blog-python-2-3/.' Installing multiversion. Generated interpreter 'blog-python-2-3/bin/py'. Installing test. Generated script 'blog-python-2-3/bin/test'.
We now have a build environment that builds single-source code for both Python 2.7 and 3.2 using zc.buildout. Of course, this technique could be extended to support even more versions. But I hope that the incompatible packages will be updated in the near future so that the need for special-case buildout.cfg files will go away. What seems to be most missing: a release of zc.buildout that supports all major Python versions.
TL;DR
- Use a current virtualenv version.
- Use a compatible bootstrap.py.
- Pin your package versions.
- Versions for some packages (including zc.buildout) must be special-cased.
Acknowledgements
I would like to thank Andrei Chirila and Michael Howitz for a great sprint session.
Take a look at https://github.com/buildout/buildout/issues/27 — the goal is to be able to have buildouts that work in both Python 2 and Python 3 with a single `buildout.cfg`. It appears that it **almost** works – it works for me with a system Python 3 but not with a virtualenv Python 3. Maybe you know why and can chime in there?
I got a single-config buildout working with zc.buildout 2.0.0a5 and virtualenv 1.8.2. On some occasions after upgrading virtualenv and switching Python versions, virtualenv got somehow confused. I deleted the local lib directory and re-created my virtualenvs for both Python 2.7 and 3.2 as outlined in the blogpost.
Please note that I refrain from using activate/deactive since it involves too much magic. I prefer to call the Python interpreter with its relative path. Since buildout puts the full path to the python executable into all generated scripts, this is as convenient to use as activate.
I’ve managed to get rid of the special-case buildout-2.x.cfg. This means that we finally need only one configuration for both Python versions.
The most important changes:
In summary, I changed the following parts of buildout.cfg compared to the article above:
[buildout]
find-links = https://github.com/buildout/buildout/downloads
...
[versions]
zc.buildout = 2.0.0a5
zc.recipe.egg = 2.0.0a3
zc.recipe.testrunner = 1.3.0
...
You can find the full sources at http://download.gocept.com/packages/multiversion-0.2.tar.gz.
After making these changes, building the project with both Python 3.2 and Python 2.7 is super easy. The shell invocations differ only in the Python version number and nothing else:
virtualenv -p python3.2 .
bin/python3.2 bootstrap.py -t
bin/buildout
bin/test
and
virtualenv -p python2.7 .
bin/python2.7 bootstrap.py -t
bin/buildout
bin/test