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.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
Many people use
requirements.txt files to list their dependencies. They
setup.py for libraries or apps that they publish. But why not use
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
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.
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
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 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.
Photo explanation: when illuminated, this is what you see of the office.
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.
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):