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 MANIFEST.in, setup.cfg, setup.py. And the actual project code is in a subdirectory, as that’s what setup.py 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 setup.py for libraries or apps that they publish. But why not use the setup.py 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 setup.py. This includes the dependencies. Your setup.py will now look like this:

from setuptools import setup

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 MANIFEST.in: 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 setup.py 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:

Summary:

  • 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 https://slides.keimlink.de

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.

https://abload.de/img/screenshot2018-02-25ajqspm.png

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

 
vanrees.org logo

Reinout van Rees

My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.

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):