De-Dependency December
As we mature, the dependency graph matures with us.
Exposition
In the occasional fights between system and language packagers, I'm known to take the downstream camp. As a user, there are lots of things I take for granted. I install the stuff I need, occasionally upgrade the system, and everything gets updated. Vulnerability in a library used by multiple programs? Its patched version gets swapped in within a few hours (given it's not vendored or pinned). Most distributions even apply hardening flags that some bugs aren't even exploitable in the first place. They create a safe place for me to comfortably express myself at work and at home.
Recently on my work computer, I've switched to Guix System, which has yet many packages. Looking into the way to package programs I use and ongoing efforts, I realized the colossal number of transitive dependencies of certain software and the impracticality for a user union (i.e. a distro) to maintain such set of micro packages in every language.
Confrontation
This gave me a more serious thought on software sustainability. Such topic often reminds us of energy consumption, modularity, development model, or even style (clean code). End-users (including self-hosts), on the other hand, ask the following questions to decide upon installing and keeping a piece of software:
Can I trust installing this won't do anything funny to my machine?
How much effort I need to prevent people from doing funny things to my machine if the software includes something that gets on the front page of some magazines tomorrow?
How much of my limited resources will it take to run or simply exist?
There are certain intersections in concerns of enterprises and users, however it's worth noticing that distributions are almost exclusively optimized to cater for the users' need. Not only they fight for the users, they are the users. Suppose you don't want to write yellow-glowing programs, you should make the life of downstream package maintainers easier. No, it does not count if you push them to give in to run go mod vendor or download from NPM recursively.
Resolution
So how do I write software that is easy to package, you may ask. If you followed the articles linked above, you've probably already figured that out. It's less about what you write and more about what you use. When someone complains a program is difficult to build from source, certainly it's not about how hard it is to type, say make install, but acquiring the dependencies for that to run successfully and the result will work.
Lower the number of dependencies will absolutely help. To put it bluntly, you can't have a problem with dependencies if there's none of them. This sounds like reinventing the wheel, but if the use case is common enough, you might find what you need in the standard library.[1] I've been restricting myself from using third-party libraries for new side projects and it actually worked for my most recent ones:
Phylactery, a static comics web server on Go with CBZ parsing and concurrent request handling
Fead, an SSG plugin in Python for advertising others’ feed with parallel HTTP request, parsing of RSS 2 and Atom and CLI argument parsing
Even for such simple use cases, there are still many libraries in the wild that can handle more data formats, are more convenient to use or more performant. On the other hand, the amount of maintenance needed to keep the programs safe indefinitely for a user is much lower thanks to the small dependency footprint.
What I'm asking you to give a try in the advent days[2] is not as drastic. Look through your works, find a library you require for a small portion of its power, or something can be implemented specifically for your project using reasonable effort (w.r.t. the whole codebase). This is not just for the sake of maintainability: being less general, the new implementation can likely outperform the replaced public library.
In many cases, you will find yourself making use of the standard library. Standards make life much easier, if only people can come up with an agreement. Or maybe they don't have to. Maybe each could choose among the utilities libraries. At the end of the day, it's the total number of packages that can have bugs to be reported upstream and patched that matters.
That being said, please keep an eye on the standard library the same way you (should) watch your other dependencies, just in case what you need is finally added. Worry not of backward incompatibility, users of LTS systems are content with older versions of your software.
Fall and Catastrophe
Just kidding, I'm offering answers, not tragedies. Winter is coming, join me in a De-Dependency December and fight for the users!
| [1] | Unless you use Rust. |
| [2] | I'm not Christian, but I had fun with AoC and Neopets before. |
Comments
Follow the anchor in an author's name to reply. Please read the rules before commenting.