In spite of all the advances that we’ve had in package management for software in the last however-many-years, managing dependencies within a project is still not a 100% solved problem. There is still, and may always be, a human element to the problem and solution.
A Version Problem
I spent about 5 minutes panicking as I saw SignalLeaf‘s media server returning a 500 Internal Server error after doing a deploy, recently:
This had me scratching my head and wondering. How is it that my local version works and when I deploy it breaks? I’ve seen this happen before, though, so the first thing I did was check to make sure that package.json file was set correctly. I wanted to make sure it didn’t have the default “*” setting for the jade package… and it didn’t.
Then I started wondering, which version was actually installed on my local box. So I ran
npm list and found out that I had jade v1.1.4 installed on my local machine. Apparently I had updated my package.json file with a newer version of jade but never installed it locally. When I deployed to heroku, it grabbed the version specified and started throwing the error above. I corrected the package.json to use jade v1.1.4 and re-deployed. The site came back up and all was well … or, well… everything except for my faith in package managers.
A Human Problem
This is only one of a dozen problems that I’ve had with package managers lately. From apt-get on Ubuntu Linux, to homebrew on mac, to npm, nuget, rubygems, composer and a few other package managers for both operating systems and language platforms / runtimes, I seem to continuously run in to problems. The thing that I’ve realized about these problems recently, is that most of them are still human problems.
Humans still specify the versions of things that they need – both for software packages and dependencies in those packages. Humans also specify the version of package they are writing. When you combine machines trying to faithfully reproduce the intent of a human, with a human’s consistent failure in expressing intent correctly (we all make assumptions that we don’t recognize), you end up with hilariously bad situations.
- One package won’t use Semantic Versioning (SemVer), while another does and depends on the first
- A developer decides to put “*” as the dependent version for a package
- Someone else adds breaking changes to a package that is supposed to using SemVer and only updates the 3rd dot number
The list of problems goes on and on and one, because package managers are still a human problem.
Still Worth Using
Don’t get me wrong, here. I’m not saying package managers aren’t worth it or don’t solve any problems. They do solve a problem of downloading and making available specific packages at specific version numbers. They also attempt to satisfy all of the dependency needs of the package your installing. But there are still problems with these package managers, and there is still a human element to them – and I believe there always will be a human element involved. Unless we can take people out of software development (yeah, right… artificial intelligence, anyone?), we will always face the uncertainty of humans being involved in our software. Keep this in mind as you build packages, set version numbers and list dependencies.