Go vgo: Semantic Versioning and Human Error

Re:Go vgo: Semantic Versioning and Human Error by rwcarlsen on Monday May 21, 2018 @04:32PM (#17121592)

For the uninitiated, vgo has a way to blacklist/exclude certain versions of dependency modules, but it only works for the top-level module being built. Exclusions from deeper dependencies are not honored in order to avoid an np-complete satisfiability problem (https://research.swtch.com/vgo-mvs).

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by mfer on Monday May 21, 2018 @04:44PM (#17121684)

Two quick thoughts...

1. By not automatically hoisting that information there is a requirement for the developer to know those details for all transitive dependencies and handle those issues themselves. A task that was automated under dep (and in other languages) is now a manual task in vgo. I do not look forward to doing that when I import Kubernetes into a project as a dependency.

2. Writing a solver that can work over a rather large codebase (e.g., kubernetes) in a timely manner (as fast as those for other languages) can and has been done. Why are we trying to avoid satisfaction problems, whom do they benefit, and why?

[ Parent | on HN ]

Re:Go vgo: Semantic Versioning and Human Error by infogulch on Monday May 21, 2018 @05:39PM (#17122071)

Dependencies' exclusions are not honored, but what if an exclusion produces a warning or notice if MVS happens to select that exclusion?

That would help solve the problem of you not knowing that a later version inadvertently breaks a dependency without taking away your (as the top-level module maintainer) choice.

[ Parent | on HN ]