Comment by jitl | Hacker News Reader

Comment by jitl | Hacker News Reader

Parent Full thread

You're right, MVS is deterministic without a lockfile, which is what you're asserting it solves.

The issue it does have is one where a transitive dependency is known bad by one of your immediate dependencies, but there's no way to declare that to the resolver.

Here's a concrete case:

1. I depend on cool-framework, min 1.5.0

2. I depend on boring-library, min 1.0.0

3. cool-framework depends on boring-library, min 1.0.0

4. cool-framework receives bug reports that boring-library 1.5.0 breaks cool-framework.

5. I upgrade boring-library to min 1.5.0. Everything builds and tests okay, but I get breakage in my staging env.

There wasn't non-deterministic package install behavior, but I still ended up with breakage that could have been prevented after (4) in a system that allows library dependencies to articulate more complex version constraints than "min version". In Rubygems or Python, with or without a lockfile, cool-framework could update its dependency on boring-library to specify "min 1.0.0, less-than 1.5.0" until the breakage is fixed.

Ok so what happens when boring-library v1.5.1 is released that fixes the breakage, right after the maintainer of cool-framework goes on vacation? Now you have the opposite problem: you can't update to a perfectly compatible version because one of your dependencies can enforce arbitrarily complex constraints on which libraries you can include. Now the problem isn't a simple "oops gotta revert the upgrade until later" which either library can fix, now the issue is that one of your dependencies is blocking all upgrades for (now) no reason.

There are problems either way. I think the other benefits that MVS enables is worth choosing one of these problems over the other.

Edit: As mentioned upthread, vgo supports exclusions for the top-level module. This doesn't directly help here currently, but what if exclusions in dependencies produced a warning of a possible incompatibility instead? I think that would solve the issue of you not knowing that an upgrade could break things.

I think a pretty good spot in the design space would be to respect specified incompatibilities with specific versions, but not ranges. Maybe even require a comment attached to the incompatibility constraint, which would explain the problem.

Bugs happen, and users should have some tools for that situation, but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it.

> but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it.

Your assumption here is that it was the boring-library version 1.5 that was broken, in reality it could be that they changed something that wasn't documented and was only an implementation detail, but was relied on by cool-framework (e.g. getting a list back sorted in one particular way in 1.4 and sorted in another way in 1.5 where the order was never part of the API contract).

Good point. In this case, the bug is in cool-framework, and I don't know that I see a great solution, regardless of the expressiveness of the constraint system. Ultimately I don't think there's a way to rule that out short of specifying exact versions. Unfortunately you can't retroactively change the version bounds for an existing release, so any library that specifies an upper bound admitting any yet-to-be-released version runs this risk.

Maximum bounds only help you if cool-framework developer knew about the incompatibility with boring-library when version 1.5.0 of cool-framework was released. If boring-library 1.5.0 was released after cool-framework 1.5.0 or the author of cool-framework didn't know you have a version of cool-framework that falsely claims to be compatible with boring-library 1.5.0 and whatever solver you use will be ok with that.

Reply on news.ycombinator.com