Djangocon: can packaging improve django deployments? - Markus Zapke-Gründemann

Tags: djangocon, django, python

(One of my summaries of a talk at the 2018 european djangocon.)

Markus started created websites at the end of the 1990s. He calls himself an open source software developers. Open source is how he learned programming, so he likes giving back.

How can packaging make deployments easier, faster and more reliable?

He showed a django project structure, modified for packaging it with python. Extra files are, setup.cfg, And the actual project code is in a subdirectory, as that’s what likes. If you have apps, he suggests to put them in an yourproject/apps/ subdirectory.

Many people use requirements.txt files to list their dependencies. They only use for libraries or apps that they publish. But why not use the also for projects? There’s an install_requires key you can use for mentioning your dependencies.

Note that if your setuptools is new enough, you can put everything into setup.cfg instead of having it all in a weird function in This includes the dependencies. Your will now look like this:

from setuptools import setup


As we’re deploying a project (instead of a library), we can even pin the requirements to specific versions.

He mentioned bumpversion to update your version number.

Regarding the it lists the files you want to include in the package. You can install the check-manifest package to test your manifest.

Building the package: python bdist_wheel. You get a python wheel out of this.

What he uses for deployment is pip-tools. There are more modern alternatives, but he thinks they’re not ready yet. With pip-tools he generates a constraints.txt. Basically a requirements.txt, but then for the dependencies of the packages in your requirements.txt. You can pass the constraints file to pip install with -c constraints.txt.

How to serve the package? You can use “devpi” to host your own private python package index.

How to change settings? Use environment variables. Except for the secrets. Use a vault for this if possible. There are some python packages that can help you with environment variables:


  • If you package your django project as a python package, you’re hosting provider independent.

  • And you use tools you already know: it prevents the not-invented-here syndrome.

  • It improves deployment to many servers.

  • The same release is used everywhere: dev, CI, staging, production.

  • And: rollback is easy.

  • Nice: a built distribution requires no build steps.

His slides are at

Some notes/comments from myself:

  • I’m starting to like pipenv, which does the requirements/constraints handling automatically. And in a more elegant way. The big advantage is that you don’t have to remember to pass the correct arguments all the time. Much safer that way (in my opinion).

  • He mentioned “bumpversion”. I myself wrote and use zest.releaser, which also updates your changelog, has a plugin mechanism, etc. It is widely used.

Photo explanation: when illuminated, this is what you see of the office. logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):