Dependency bloat and dependency bitrot have made solutions less permanent, have increased the maintenance burden. My ancient projects with zero dependencies still stand. But projects I built on shifting dependencies are rotting and cracking.
Dependency bloat and dependency bitrot have made solutions less permanent, have increased the maintenance burden. My ancient projects with zero dependencies still stand. But projects I built on shifting dependencies are rotting and cracking.
This is why is like pure C/C++ projects with zero dependencies beyond the standard library, and this is certainly what I do for my numerical work. If some external library is needed, the source files of the dependency are downloaded, compiled, and kept as part of the project itself, so that it can always be rebuilt and reused if necessary. Of course, depending on what you do, this may not be practical, although LLMs certainly have made it much easier to generate the dependencies in house, so to speak.
Do the versions of the dependencies that you used no longer exist anywhere?
Fair counter, and that's the right stance. The tax I'm pointing at is the implicit social one: feeling like you owe a response. Plenty of publishers get burned out before they figure out your model.
they exist, but they are likely unmaintained, and may have known security issues.
i have a project that suffers from that. the version of a library it is built with is old and unsecure, but the newer supported version has a completely different API that would require me to rewrite the code that uses the library.
i had a second such case where i discovered a fork of the old version of the library which was still maintained. otherwise there too a rewrite would have been required.
In my experience, the most common problem is that a dependency changes. It drops support for something, API changing, etc. If it's 3 dependencies deep, and one of the deps in the middle isn't maintained anymore, well...