We’ve been using zc.buildout for Plone deployment and it’s working out great. A few days ago implemented a buildout recipe for Django project deployment, automatic web configuration, symlinking, media-folder structuring etc. and while I got it working, I came up with twisted feelings.
Buildout is from the creators of Zope (I suppose) so you can expect a powerful project code management tool. The question is, however, whether or not it suits your needs. In my case I found out it too heavy. I mean, to add even a simple task you have to create a new “recipe” (a package) that does the tricks. Of course some recipes are generic (found from PyPi) and you can just run them with your own INI options, but in my case I had to do some custom implementation. Creating a new python package isn’t that hard for sure 🙂 but there’s of course some learning curve, so the real question is should you spend time to learn it or not?
I found out that zc.buildout has some nice features like:
- Automatic requirements processing through setuptools
- Automatic (yet simple) removal of directories during recipe uninstall
- Clear structure (install(), update() & uninstall() methods)
- INI-syntax, python does have a clear syntax but INI is always clearer for a newbie
- Easy script creation (adjust python paths somewhat automatically)
- Easily repeatable
- Passing of arguments from one recipe to another
- etc.
The problems?
- It takes a while to learn zc.buildout
- It takes ‘another while’ to learn to write recipes
- Too much hassle for little things
- INI-syntax is very limited in features
- Buildout easily updates all your packages (that means also the ones you didn’t want to!)
- Lack of documentation (it has good docs to get you going.. but after a while it leaves you with open questions)
- Unnecessary overhead (for each script you launch, you’ll need a launcher script created via buildout)
There’s no denying zc.buildout is powerful, but I wouldn’t use it for projects which need reasonable amount of customization. It’s just plain easier and quicker to write shell scripts and while those won’t provide you with any sort of ready tools you won’t propably need them. For bringing up somewhat static environment, where you don’t need to hack things (like that for Plone) it’s quite a decent option, however.
I also explored alternatives to zc.buildout. I’ve been reading about earlier virtualenv but haven’t really tried it out until now. It looks very promising and creates a more flexible environment compared to zc.buildout. Of course their goals are not exactly the same. Also, there are a few other alternatives out there, among them a new Python code management tool called Paver (just look at that cool logo.. it does remind you of Indiana Jones, does it not?). I glanced through the Paver docs and it looks like it might be the way to go (Paver also supports virtualenv), but didn’t quite get the grasp of the benefits just yet. Anyway, if you are still interested in code management and deployment, I’d recommend you to read the Paver release announcement and also Paver forewords. They should clear things up.
Shell scripts are sometimes difficult too. Let’s not forget GNU make either; a single Makefile could more often than not be the easiest way to install dependencies…
I’ve recently settled on this workflow when using buildout: create a new virtualenv project, install inside it zc.buildout, then run my buildout. If you’re concerned with the fact that you get breakages from updating packages, you can either: specify a versions section in buildout.cfg, or run buildout with the -N switch, or specify versions for required packages inside your setup.py (if you’re developing a new package). As the author of a zc.buildout recipe I can attest that writing one is not a very complex task and there are sufficient minimal examples to get you started.
Hi Tuukka,
Thanks for putting together a succinct overview of zc.buildout (which I think will be useful for a lot of folks who have never tried it) and for mentioning Paver.
I’ve found Paver to be a great tool for scripting my projects. Just a thin layer over standard Python (rather than trying to build a DSL of sorts in an INI file).
Currently in bzr on launchpad, Paver has grown support for Virtualenv+PoachEggs. In a couple of weeks, I’m planning to add some remote deployment support. That will really flesh out the deployment part of the picture for Paver.
Kevin
@Â Tiberiue: I didn’t mean buildout was difficult, but that it will take some time to learn. In that time you could have written a quick shell script and get well along with your project. I mean, if you want to just run some shell command, say ‘netstat -r’ and get the output, you need a recipe for that. Now how to create a recipe when you don’t know how? Read through the docs and learn it, then debug some of the issues and try to resolve the rest of the things by looking at buildout source code. If we could do this with plain python it might take a lot less time.
As for the package upgrading, yes, version/revision information does that but I’m just too lazy to write them up 🙂 It’s easier just to do the update for selected packages when I want it (maybe buildout could allow executing a single part from command line).
@ Kevin: remote deployment sounds nice although it cannot replace the manual ssh’ing. Given a good set of tools, however, it might ease out lots of things. I definitely have to check that out then..