(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.
Photo explanation: when illuminated, this is what you see of the office.
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.
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):