Dependency hell strategies

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the dependencies category.

Last Updated: 2024-03-02

Strategy 1: Set to the maximum version released at time of intermediate dep

I tried to get a python library working for car-damage-detection. The last commit for this library was 2 years ago. Running pip install -r requirements.txt resulted in incorrect version numbers, because they were far too new and the requirements were written with version numbers >X (i.e. no exact versions pinned). The trick to getting it working was to constrain to version numbers available then

Strategy 2: Update all dependencies

In greenfieldish / heavily tested codebases only....

When hopelessly trapped in dependency hell, try running the package manager update on all existing packages. Case in point: I was unable to install Laravel 5.8 in a codebase using Laravel 5.7. No matter what, some other package version requirements would cry foul and prevent the install from working.

At first, I was scared to upgrade all the packages with composer update so I avoided it and tried updating single packages and deleting the vendor folder.

But ultimately the only thing that worked was updating all with composer update

Strategy 3: Realize that dependencies can be constrained by the language version number

I tried to get a python keras library to install at specific version with pip, but it refused to do it. After Googling, I realized that the version of keras I wanted only supported a lower version of Python. And by downgrading to that python version, I was able to install the dependency.

Strategy 4: Realize the max version of a programming language that is installable can be limited by the operating system version

For example, I was unable to install python 3.8 on Ubuntu 16. I needed to create a new server with Ubuntu 18.