The other day, I finally got around to updating the very server that this blog lives on, alongside a few other pet projects.
I set this server up 4 years ago, running Ubuntu 16.04. I recall that I did this once before as well, upgrading from Ubuntu 14.04 or something. What’s this that I did? I remember that after about 10 minutes of research, I figured it was faster, easier, and less painful to simply create a new virtual machine, install a web server, and copy my files over, so that’s what I did.
This time, I thought I’d try out Ubuntu’s built-in upgrade capability. After
all, whenever I would SSH in, I’d always be reminded that it’s as easy as
do-release-upgrade. I just ignored it over and over. My little virtual
machine seemed to chug along just fine without an upgrade. When Ubuntu 22.04
came out, I felt it was time to upgrade.
I knew that trouble was cooking when do-release-upgrade started spitting out
error messages a few seconds into the process. Apparently I had waited too long
to upgrade, and I would have to manually add a few lines to my sources.list to
make it work.
That seemed to fix the first issue, so I continued through a few smaller error messages, conflicting dependencies, and so on. Each time, I thought for sure it might start the upgrade process without running into yet another error message, and each time I was disappointed. This is exactly what I must have experienced the first time, because I decided that, rather than wait for the endless error messages to cease, it would be easier, once again, to start fresh.
I’m glad I did, because in the meantime it seems that the industry stopped offering the tiny 512 MB virtual machine, so for the same price I now have a whole 1 GB of memory! That’s when it hit me how long this thing had been running, and how much time has passed since I set it up.
For the new virtual machine, I went with Debian so that it would be a little less bloated. Setting up the new VM was a breeze, but while moving some old projects over, I was given one final reminder of how software rots surprisingly fast, and why it’s good to not over-engineer things.
I had one little project, that didn’t even do much, not make it to the new server.
It’s such a harmless little thing, just a small website, whose dependencies choked it one final time.
To make it look good, and for its layout to be functional, I used a CSS framework.
I assume this CSS framework, at least back in the day, required Sass to build the final stylesheet.
To facilitate the build process, I used Gulp, a tool which was the hottest thing at the time, so that must have been the reason why I intertwined it with this project. Today it’s hilariously outdated in a software timescale, not having had a release since May 2019.
Alright, time to build the files so that I can host it on my new server. I haven’t changed the code, so it should still work, right?
A few
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
was expected.
Then came the slew of messages from package maintainers who have gone on to other things.
Then it exploded with
npm ERR! gyp ERR! stack Error: Command failed: /usr/bin/python -c import sys; print "%s.%s.%s" % sys.version_info[:3];
Ah, yes, we can all guess what that means.
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
It’s a gravestone of a five year struggle to finally stop supporting Python 2, which at last happened in 2020, twelve years after the release of Python 3.
What does that have to do with my Node.js packages?
I could probably figure out, but like my server, sometimes it’s easier to nuke the whole thing and start fresh.
The next time I build a project like this, I’ll keep in mind that one day the dependencies will come back to haunt me, so I’d better have as few as possible.
If it takes only a few short years to cripple software like this, then maybe that’s
not ok
as the last line of output in my attempt at npm i suggested.