cmd/go: for @latest and @upgrade, ignore +incompatible versions if the latest compatible one has a go.mod file #34165
Comments
go get -u updates to incompatible module versiongo get -u updates to incompatible v2 module version
go get -u updates to incompatible v2 module versiongo get -u updates indirect dependency to incompatible v2 module version
|
I've added https://github.com/andig/blackfriday/ for a small demo of the |
go get -u updates indirect dependency to incompatible v2 module versiongo get -u updates dependency to incompatible v2 module version
|
/cc @bcmills @jayconrod |
|
This is currently working as designed, but the behavior is unfortunate. #34217 discusses some alternative behaviors. The reason this happens is that a #34217 is a pretty large proposal, but perhaps a narrower fix for this issue would be that |
Could you elaborate on that? There ist a go.mod file in place: https://github.com/russross/blackfriday/blob/master/go.mod Or is what we‘re seeing here (keeping https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher in mind) the added case of a go.mod in place but not following the spec for case 1) where it needs to add a /v2 to the module name? |
Not in The At any rate, because |
|
If we don't do #34217, then we should consider this as an alternative. If there is no existing requirement on a module at all, we should probably also prefer the latest compatible version with a Unfortunately, that doesn't address the problem of what to do if one of your dependencies already |
That is indeed very unfortunate as it seems to contradict semver or just expected behavior.
+1. I do not understand the incompatible use case (need to read up) but sticking to compatible versions would be what I‘d expect without reading the docs. |
go get -u updates dependency to incompatible v2 module version|
I think we should do this in 1.14. I'll see if I can get something in before the freeze. |
|
Change https://golang.org/cl/204440 mentions this issue: |
|
Change https://golang.org/cl/204439 mentions this issue: |
codeRepo.Versions previously checked every possible +incompatible version for a 'go.mod' file. That is wasteful and counterproductive. It is wasteful because typically, a project will adopt modules at some major version, after which they will (be required to) use semantic import paths for future major versions. It is counterproductive because it causes an accidental '+incompatible' tag to exist, and no compatible tag can have higher semantic precedence. This change prunes out some of the +incompatible versions in codeRepo.Versions, eliminating the “wasteful” part but not all of the “counterproductive” part: the extraneous versions can still be fetched explicitly, and proxies may include them in the @v/list endpoint. Updates #34165 Updates #34189 Updates #34533 Change-Id: Ifc52c725aa396f7fde2afc727d0d5950acd06946 Reviewed-on: https://go-review.googlesource.com/c/go/+/204439 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
|
Change https://golang.org/cl/212317 mentions this issue: |
|
We discovered a regression for certain queries (such as The fix is under review at https://golang.org/cl/212317. |
|
The regression is now fixed. |
We know of at least one module (github.com/stripe/stripe-go) that has a run of +incompatible versions, followed by a run of versions with go.mod files, followed by another run of +incompatible versions. We want the heuristics for showing +incompatible versions to reflect the authors' current intent, and it seems clear that the current intent of the authors of that module is for users of the unversioned import path to still be on +incompatible versions. To respect that intent, we need to keep checking for +incompatible versions even after we have seen a lower major version with an explicit go.mod file. However, we still don't want to download every single version of the module to check it. A given major version should have a consistent, canonical import path, so the path (as inferred by the presence or absence of a go.mod file) should be the same for every release across that major version. To avoid unnecessary overhead — and to allow module authors to correct accidental changes to a major version's import path — we check only the most recent release of each major version. If a release accidentally changes the import path in either direction (by deleting or adding a go.mod file), it can be corrected by issuing a single subsequent release of that major version to restore the correct path. I manually verified that, with this change, github.com/stripe/stripe-go@latest reverts to v68.7.0+incompatible as it was in Go 1.13. The other regression tests for #34165 continue to pass. Updates #34165 Change-Id: I5daff3cd2123f94c7c49519babf4eecd509f169e Reviewed-on: https://go-review.googlesource.com/c/go/+/212317 Reviewed-by: Jay Conrod <jayconrod@google.com>
What version of Go are you using (
go version)?I've also seen this on go1.12, so its not recently introduced.
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I'm using
github.com/spf13/cobra/doc, with cobra locked in mygo.mod:cobra/docindirectly depends on blackfriday:What did you expect to see?
Running
go get -uI expect module updates. As for blackfriday, that update should remain in the compatible v1 import path.What did you see instead?
The error is due to pulling blackfriday v2 into
go.modwhich does not have the required constants from 1.5.2 anymore (https://github.com/russross/blackfriday/tree/v2):I feel that
go get -ushould not pull in the blackfriday v2 dependency as it is not used. md2man in its latest version still relies on 1.5.2 so import path should not change (https://github.com/cpuguy83/go-md2man/blob/7762f7e404f8416dfa1d9bb6a8c192aa9acb4d19/go.mod):Refs cpuguy83/go-md2man#48
The text was updated successfully, but these errors were encountered: