3 ms·
So what's happened here is there's a bug in in gRPC 1.8. What the OP wants is a way to say, "hey, our software is broken with this buggy version of gRPC," as p
by dilap 8y ago
So what's happened here is there's a bug in in gRPC 1.8.
What the OP wants is a way to say, "hey, our software is broken with this buggy version of gRPC," as part of the dependency requirements. I can see some value in that, but it also feels like a case where just documenting it in the README would not be super-unreasonable.
As a practical matter, any time a dependency A says it wants some other dependency B at version V, if you are using B at a version U>V, you are running in a untested configuration, and may encounter problems. (But! this will only happen if you are specifically requesting U>V, or if you have some other requirement A2 requesting B@U. In the latter case, again, you are running a new, untested combination of software, and there might be problems.)
An alternative to this would just be allowing multiple copies of B at the same major revision, B.U and B.V. But due to Go's use of package-level global variables, that is just as likely, if not more so, to cause bugs, since not all packages will see the same set of shared variables.
It does seem like extending the vgo to allow != version requirements might be reasonable. Not full-on <=, which breaks builds or leaves them unsat forever, but just a != to say "hey this version is buggy and we know we don't work with it."
- RVuRnvbM2e 8y ago> So what's happened here is there's a bug in in gRPC 1.8. Yeah I don't understand how this is vgo's problem. In the follup post it shows that they are importing the buggy gRPC version directly: https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/ https://codeengineered.com/blog/2018/golang-vgo-broken-dep-t... So doesn't that mean that they can just file a bug report upstream to get the regression fixed in 1.8.1, and exclude 1.8.0 in the meantime?
- dolmen 8y agoI agree. I don't see a vgo issue. The behavior in the example was broken by a release, but could have as well been restored by a patch release as restoring behaviour would not have broken the API. See https://news.ycombinator.com/item?id=17123583 https://news.ycombinator.com/item?id=17123583
- mzl 8y agoFor vgo there is an explicit goal is to avoid NP-completeness for some reason. Systems of not-equals are NP-hard (trivially models 3-colouring), so allowing not-equals constraints on package versions is a non-starter if the stated goals of vgo are to be maintained. Personally I think that some kind !=-requirements are needed for package managers just for this case, and thus the choice of dependency resolution approach vgo has is wrong IMHO.