There's a fair middle ground when the dependency in itself doesn't have dependencies, and is small enough with a permissive license such that the entirety of its code can be dropped in to your project. Especially for very specific functionalities. I have used such tiny xml parsers, and I'm not affected by the fact that my copy is no longer the latest version. Its not so far from copying and pasting snippets of existing code.
So true. You always have to weight the cost of carrying around a dependency and what that will mean for others who will have to use and build your code in the future and on platforms like Windows where dependency resolution is far from trivial. Seen this way sometimes it's worth spending a few of hours writing a JSON parser to avoid adding a dependency. Probably not woth an XML parser though.
Depends on what it is you need. If you really have a small need, then taking a giant dependency is very possibly a bad idea. But I have seen the opposite pretty often. “I don’t need that library. I just need this one thing. Okay, this other thing, and this. And this and this and this.” And by the time they’re done they’ve reimplemented 75% of the library in a far worse way.
The most egregious example I ever saw was reimplementation of xml parsing with C++ substrings. They “didn’t need” a real xml parser. In the end, they found endless bugs with their shitty parsing logic and it turns it it was responsible for something like 50% of the (very large scale) system resource use.
There is a middle ground between hundreds of thousands of untested, unaudited implementations of a roughly-similar functions, and packages which auto update without the developer doing anything at all.
At the least you want some oversight when a dependency changes under you.
Ideally you would choose dependencies with minimal dependencies of their own (very few if any common dependencies), so you have a manageable number of versions and near complete freedom of choice of those versions.
You're right, by trusting any outside source for a dependency, you're still dependent. But as you noted, there's the option of adopting the software yourself and injecting it as vendored or something similar. Proprietary doesn't even have that.
Depending on the project, it may move slow enough for the dependency to be slow to update and it be fine. Depends on what you're doing.
At least in the case you mentioned, I can revert to an older version and freeze it there until my business can sort out the way forward.
Ideally, one chooses dependencies that are easy to replace and reasonable to maintain for a bit, if needed. Or if you're lucky, no dependencies at all!
My point is that if you install the code through a dependency of a dependency it should be leaving license notices entirely intact, fulfilling the license.
Of course javascript optimizers and the like might throw a wrench in the works these days, but that's a pretty recent and specific problem.
This is not only an issue for running software but also a huge issue for compiling/building software. Each dependency adds the potential to break your builds in new ways. As the software your program depends on evolves the risk increases that it will change the way your program executes or cause it to fail to build. Many devs will insist you do not reinvent the wheel by writing things like JSON parsers but you always have to weigh the cost of adding a dependency. It's not free.
The risk is still there for dependencies, but it helps that the community for the most part follows "a little copying is better than a little dependency" as an adage.
The problem here is that any code run during development could generate code that ends up in production. Even if the dependency isn't used in production, there is a "compile step" (though it's technically transpiled) during which all sorts of mayhem could ensue.
Yeah in the debate about dependencies, people often frame it as more dependencies == bad and less dependencies == good. Except more/less dependencies is actually more or less explicit dependencies. Fact of the matter is that you need a crazy amount of dependencies to write most modern software. You need ways to handle Unicode, to connect to databases, to write async code, to handle dates, etc.
The question is whether that code is going to come from a monolithic Swiss Army Knife of a library (aka a standard library), a bunch of packages, or some code that everybody copies into their codebase. In which case the packages option doesn't seem so bad. At least they're explicitly versioned, tracked for vulnerabilities and can be updated at a granular level.
We'll have to agree to disagree if you see equivalence there.
Even the smallest transitive dependency in our largest dependency graph in the Java ecosystem isn't someone's 6-liner afternoon project.
I think the ease of publishing + ecosystem of small modules is a good thing, it just has what we consider an ecosystem-level security trade-off that matters for some applications.
If your software is not publicly accessible, it may be possible for you to continue running on 10+ year old dependencies indefinitely. For anyone else, other than a hobbyist, it is just not practical.
Otherwise, you are going to be influenced by external factors (security vulnerabilities, wanting to use a feature only available on a newer language version or OS, etc.) If you are a business, you'll also run into more practical concerns, like engineers not wanting to work on a mountain of technical debt.
My issues is not the runtime dependency but the development dependancy. As the production apps I am responsible for keep getting older and older my opinions on ruthlessly cutting decencies get stronger and stronger.
Somewhere there's probably an optimal expected lifespan of a program where the line between preferring a better language and fewer development dependencies is crossed, but I'm also starting to learn that software stays around years longer than I ever anticipated.
reply