dependency management problems are a thing irrespective of the license of those dependencies. nobody anywhere is writing assembly code entirely on their own, even then you depend on a compiler. every software project has dependencies. it's a problem solved by version pinning. i can't believe a tech writer wrote this?

5
12
@Gargron version pinning means you are potentially missing important bug fixes during codebase refactoring which were actually vulnerability fixes that didn’t get CVEs assigned
0
1
Eugen
Follow

@feld no. you gotta be paying attention to new releases of your dependencies (there are tools for this), but version pinning means you don't get unexpected breaking changes from someone else's code.

· Web · 1 · 1
I second that, you can't just trust an automatic dependency updater to keep your own software running. A dependency isn't entirely free work you're using from someone else; whatever the license, you have to spend at least some time managing them.
0
1
@Gargron I’ve only witnessed it used to freeze that code for eternity because keeping your codebase compatible with the latest releases of your dependencies is “too much work”
0
1

@feld @Gargron I have used it on various production systems for years so that I choose when and how to manage the complexity of upgrading a dependency instead of the dependency authors choosing. It means I can finish out some feature branch before getting into upgrade work. Or, even better, several developers on active feature branches don't all have to figure out a version upgrade just to get the project to build.

0
0
@feld @gargron So, you have the choice of auto-updating and violently breaking your thing even when there's no problem, or pinning and silently staying broken when there's a security update. :-)
0
0

@clacke @feld @Gargron Exactly. What we need, and really don't quite have yet (in general) is a way for a person or organization to subscribe to the changelogs of the dependency-tree-assuming-you-were-to-update.

I keep thinking about building this, and what it would require. And first, uh... it would require people to keep changelogs. 😭

0
0

@clacke @feld @Gargron ok first of all because I am a jerk, #semver

second of all is that really worse than *not* using open source? I mean, if you're not tracking security holes that other people find, I can't imagine you're actively looking for security holes in code only you can see

0
0
@ajordan @gargron @feld Yeah, semver intends to tell you what contracts you have with your dependencies.

But even elm, which enforces that API signatures don't change without bumping versions, cannot enforce that semantics don't change underneath the API signatures.

Short of perfect formal verification, there is no technological solution, because this is a human problem.
0
0

@clacke @feld @ajordan @Gargron Pesky, pesky humans. They always get in the way of glorious progress! 😁 In a less sarcastic vein, I have been questioning the resilience of these sprawling dependency chains after that leftpad accident with npm.

0
0

@skellat @clacke @feld @Gargron meh. Point taken, but you're going to have that problem no matter what, and there are relatively simple solutions to it. Mirroring the parts of the npm registry you depend on, for example.

npm also changed its policies after that so an incident like that can't happen in the future.

0
0

@clacke @feld @Gargron oh absolutely, semver is not without its flaws. IMO it's better than anything before it but it doesn't replace e.g. testing. This is why lockfiles exist.

0
0
@ajordan @gargron @feld Thank you, and I agree.

I think semver is a good idea and I like it. But even with semver we need lockfiles. But then with lockfiles we need to not fire-and-forget but keep up to date on things.

Belts and braces, people. Goes along with the gum and paper clips we built this stuff on.
0
0
@ajordan @feld @gargron

One thing that I want to see more of in the future is what e.g. #rust is doing:

Find the things that depend on your thing -- in their case every single crate published -- and treat them all as integration tests for your API.

#nix and #guix make this easier. I just discovered the brilliant #nox tool, where you can do `nox-review wip` on e.g. a bumped dependency and build and test every dependee.

Imagine if every project did this before releasing their point release! (and at the same time imagine that the dependees have decent tests, of course, otherwise you're just detecting whether you broke API signatures, and that's trivial to do without looking at any code except your own)
1
1

@clacke @feld @Gargron fun fact, Node.js actually has some tooling to do this! Though from your description it sounds like it's nowhere near as comprehensive as Rust's. github.com/nodejs/citgm

0
0

@clacke lmaoooo I have no idea

Maybe a semver-major change landed in git master and it's expected...? Dunno ¯\_(ツ)_/¯

0
0
Mastodon

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!