Reuse Less Software
5 points by icefox
5 points by icefox
The Zig package manager imho is a really cool compromise:
All packages are pinned with a content hash, so lockfile-by-default.
It doesn't suffer from the "upstream suddenly got malicous" problem, but still has the issue of "upstream's gone".
Except that it has both a global and local cache, content hash-addressed, so when your upstream is gone, you just yeet a tarball of your local copy where-ever you need it.
It's a really good compromise between "vendor sources" and "simple, reusable software".
Proposed solution include all the dependencies for your software, with your software. [...] Copy-paste upstream source control into your git repo and commit that fucker. [...] Get sick of doing this by hand? Make the build tool automate it, that’s its job.
And at that point we're full circle and are including 3rd party software unseen again?
Keep reading:
(You could also get the same effect by ditching any concept of semver or other “these two different pieces of code should behave the same” in the build system, and treating every version number as unique and unrelated to any other. But that doesn’t solve the problem of dependencies vanishing or otherwise being subverted, or someone tampering with the contents of a package in other ways. It’s an optimization, and in my mind a premature one; we might get there eventually but shouldn’t start there.)
But there’s one really big problem: supply chain attacks.
No signed contract with an offer and consideration; not a supply chain!
Separately, from the point of view of ensuring your dependencies don't change out from underneath you, a lock file with hashes (or the Golang minimal versioning scheme) are identical to vendoring your dependencies. I hear you on the friction argument where vendoring truly is different. But consider that in the limit, it pushes you to either write your own implementations of things, or—even worse—vibe code your dependencies, and I'd rather use well-tested software written by domain experts.
edit: wanted to add:
There’s a ceiling to the complexity this will tolerate, though companies like Google and Facebook(?) with giant monorepos demonstrate that this ceiling is probably a lot higher than you think.
I worked at Facebook on this stuff, and I wouldn't wish its third-party dependency story on anybody. (There can be at most two semver-incompatible versions of a particular direct dependency to a Rust crate across all of fbsource at any given time. If you want to update a dependency, you have to take on the burden of updating all of fbsource.) I think what Facebook does is okay for Facebook, but it isn't particularly great or sustainable.