Buildout and Django: djangorecipe updated for gunicorn support¶

Tags: django

Most people in the Django world probably use pip to install everything. I (and the company were I work, Nelen & Schuurmans) use buildout instead. If there are any other buildout users left outside of zope/plone, I’d love to hear it :-)

First the news about the new update, after that I’ll add a quick note about what’s good about buildout, ok?

Djangorecipe 2.1.1 is out. The two main improvements:

• Lots of old unused functionality has been removed. Project generation, for instance. Django’s own startproject is good enough right now. And you can also look at cookiecutter. Options like projectegg and wsgilog are gone as they’re not needed anymore.

• The latest gunicorn releases didn’t come with django support anymore. You used to have a bin/django run_gunicorn (or python manage.py run_gunicorn) management command, but now you just have to run bin/gunicorn yourproject.wsgi. And pass along an environment variable that points at your django settings.

  With the latest djangorecipe, you can add a scripts-with-settings = gunicorn option and it’ll create a bin/gunicorn-with-settings script for you that sets the environment variable automatically. Handy!

Advantage of buildout. To me, the advantage of buildout is threefold:

• Buildout is more fool-proof. With pip/virtualenv you should remember to activate the virtualenv. With buildout, the scripts themselves make sure the correct sys.path is set.

  With pip install something you shouldn’t forget the -r requirements.txt option. With buildout, the requirement restrictions (“versions”) are applied automatically.

  With pip, you need to set the django settings environment variable in production and staging. With buildout, it is just bin/django like in development: it includes the correct reference to the correct settings file automatically.

  There just isn’t anything you can forget!

• Buildout is extensible. You can extend it with “recipes”. Like a django recipe that helps with the settings and so. Or a template recipe that generates an ngnix config based on a template with the django port and hostname already filled in from the buildout config file. Or a sysegg recipe that selectively injects system packages (=hard to compile things like numpy, scipy, netcdf4).

• Buildout “composes” your entire site, as far as possible. Pip “just” grabs your python packages. Buildout can also build NPM and run grunt to grab your javascript and can automatically run bin/django collectstatic -y when you install it in production. And generate an nginx/apache file based on your config’s gunicorn port. And generate a supervisord config with the correct gunicorn call with the same port number.

Of course there are drawbacks:

• The documentation is definitively not up to the standards of django itself. Actually, I don’t really want to point at the effectively unmaintained main documentation site at http://www.buildout.org/…. You need some experience with buildout to be able to get and keep it working.

• Most people use pip.

Why do I still use it?

• The level of automation you can get with buildout (“composability”) is great.

• It is fool-proof. One bin/buildout and everything is set up correctly. Do you trust every colleague (including yourself) to remember 5 different commands to set up a full environment?

• If you don’t use buildout, you have to use pip and virtualenv. And a makefile or something like that to collect all the various parts. Or you need ansible even to set up a local environment.

• Syseggrecipe makes it easy to include system packages like numpy, scipy, mapnik and so on. Most pip-using web developers only need a handful of pure python packages. We’re deep into GIS and numpy/gdal territory. You don’t want to compile all that stuff by hand. You don’t want to have to keep track of all the development header file packages!

So… hurray for buildout and for the updated djangorecipe functionality! If you still use it, please give me some feedback at reinout@vanrees.org or in the comments below. I’ve removed quite some old functionality and I might have broken some usecases. And buildout/django ideas and thoughts are always welcome.