Dodging dependency hell
Containerisation can stop you drifting through these levels of hell.
ESCAPE THE MAZE “You often find yourself in a labyrinth comprising dead ends, broken links, absent archives, forgotten files and, eventually, rage.”
Take Python – it’s one of the most popular programming languages in the world, and has been used for millions of individual coding projects. The current version is 3.11, and while it comes with various upgrades for speed and security, it deprecates several features, functions and modules. If a Python app you wrote a few years ago uses binhex, distutils or gettext functions, it won’t run on the most up-to-date installs. While readers of Linux Format probably wouldn’t have too much of a problem specifying which Python version to use, it makes the experience more difficult than it needs to be. If you’re a developer, it means you either need to regularly go back and update your code so the app works with a broader variety of software setups, or abandon it and hope that somebody finds it useful enough to fork.
Python is an obvious example, but individual libraries can be a problem, too. If you’ve ever deployed software more than five years older than your distro release date, you’ll have run into dependency hell. Libraries and dependencies are obsolete, and you often find yourself in a labyrinth comprising dead ends, broken links, absent archives, forgotten files and, eventually, rage. In the event that you eventually find the exact version of glibstreamer you need, installing it may destroy the functionality of other apps on your system.
Historically, one way of ensuring that software will work on your system is to deploy it in a virtual machine of appropriate vintage, then create a virtual disk image (VDI). You can tote your VDI from system to system through the years, and always have a working copy of Literature & Latte’s excellent, but long abandoned, 2011 Scrivener beta for Linux.
But VMs are huge and cumbersome, and it’s ludicrous to have an entire virtual distro just to run one app.
Keep it contained
Containerisation is a different way of deploying software. It doesn’t rely on packages and dependencies you already have on your system or may need to install. Nor does it require you to spin up entire consumer-grade distros for each app you plan to use.
Instead, containerisation offers a nice middle ground without too many compromises. Each containerised app comes with everything it needs to run – and the specific version it requires. Any libraries, dependencies and other files are a specific version, and guaranteed to work with minimal fuss.
Everything in the container is isolated from the rest of your system – so if, during an upgrade, a dependency develops a breaking change, it’s not going to affect the many and varied versions in your containers. Everything carries on as normal, and what once could have been a crisis isn’t even noticed.
Granted, containerisation isn’t the slickest or most minimal way of doing things. If you run a lot of containerised apps, many of them duplicate multiple components. Some may even pull entire minimal distros such as Alpine in order to ensure an identical environment across machines.
But, hey, this is 2023. Storage is cheap and bandwidth is cheaper. Unless you’re using a Chromebook, you’ll probably be fine.