cmd/go: 'go get […]/v2@v2.X.Y' fails when the go.mod file for […]/v2 is at the repo root #34383
Comments
heschi
added
GoCommand
thepudds
changed the title
|
Seeing a similar issue with our stats package: https://gist.github.com/abraithwaite/15a0ffd0021b4539793bc0ceb1dc3bc1 |
|
This repo can consistently break the command: When the repo you run this from is lacking the broken module in it's It also fails to update the go.mod file with any version of the broken module whatsoever: |
|
For my own sanity, I checked to see if this issue could be reproduced for modules which have a "correct" git history. that is: the go.mod package directive has been updated to include the vX suffix throughout this history, for tags that reference a major version. It does still trigger the bug. This repo has the correct |
|
@gopherbot, please backport to 1.13. This is a regression, and the workaround (editing the |
|
Backport issue(s) opened: #34497 (for 1.13). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
|
This turns out to be closely related to #34432, in that we should notice the mismatched module path and treat that as a “not found” error rather than a hard error. |
Ah, so it's looking for the subdirectory erroneously? None of these repos that I've created/used have a vX subdirectory in their tree. Only git tags. |
|
It's checking whether Instead, it should notice that the module path doesn't match and ignore the repo. (As a smaller, shorter-term fix, we could apply the same solution as for #34094: if we've already found the |
I think that makes sense anyway. As a consumer, I'm surprised that the root module is even searched, but maybe that has something to do with the fact that there isn't a subdirectory for the module? Also, by "ignore the repo" you mean that it will skip |
|
Change https://golang.org/cl/197059 mentions this issue: |
bcmills
changed the title
Yes. It should interpret the mismatched path as meaning “the module |
…s already found In CL 173017, I changed the package-to-module query logic to query all possible module paths in parallel in order to reduce latency. (For long package paths, most such paths will not exist and will fail with little overhead.) The module resolution algorithm treats various kinds of non-existence as “soft errors”, to be reported only if package resolution fails, but treats any remaining errors as hard errors that should fail the query. Unfortunately, that interacted badly with the +incompatible version validation added in CL 181881, causing a regression in the 'direct' fetch path for modules using the “major branch” layout¹ with a post-v1 version on the repository's default branch. Because we did not interpret a mismatched module path as “no such module”, a go.mod file specifying the path 'example.com/foo/v2' would cause the search for module 'example.com/foo' to error out. (That regression was not caught ahead of time due to a lack of test coverage for 'go get' on a package within a /vN module.) The promotion of hard errors during parallel search also made the 'go' command less tolerant of servers that advertise 'go-import' tags for nonexistent repositories. CL 194561 mitigated that problem for HTTP servers that return code 404 or 410 for a nonexistent repository, but unfortunately a few servers in common use (notably GitLab and pre-1.9.3 releases of Gitea) do not. This change mitigates both of those failure modes by ignoring “miscellaneous” errors from shorter module paths if the requested package pattern was successfully matched against a module with a longer path. ¹https://research.swtch.com/vgo-module#from_repository_to_modules Updates #34383 Updates #34094 Change-Id: If37dc422e973eba13f3a3aeb68bc7b96e2d7f73d Reviewed-on: https://go-review.googlesource.com/c/go/+/197059 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
|
Change https://golang.org/cl/197063 mentions this issue: |
…queries if the package is already found In CL 173017, I changed the package-to-module query logic to query all possible module paths in parallel in order to reduce latency. (For long package paths, most such paths will not exist and will fail with little overhead.) The module resolution algorithm treats various kinds of non-existence as “soft errors”, to be reported only if package resolution fails, but treats any remaining errors as hard errors that should fail the query. Unfortunately, that interacted badly with the +incompatible version validation added in CL 181881, causing a regression in the 'direct' fetch path for modules using the “major branch” layout¹ with a post-v1 version on the repository's default branch. Because we did not interpret a mismatched module path as “no such module”, a go.mod file specifying the path 'example.com/foo/v2' would cause the search for module 'example.com/foo' to error out. (That regression was not caught ahead of time due to a lack of test coverage for 'go get' on a package within a /vN module.) The promotion of hard errors during parallel search also made the 'go' command less tolerant of servers that advertise 'go-import' tags for nonexistent repositories. CL 194561 mitigated that problem for HTTP servers that return code 404 or 410 for a nonexistent repository, but unfortunately a few servers in common use (notably GitLab and pre-1.9.3 releases of Gitea) do not. This change mitigates both of those failure modes by ignoring “miscellaneous” errors from shorter module paths if the requested package pattern was successfully matched against a module with a longer path. ¹https://research.swtch.com/vgo-module#from_repository_to_modules Updates #34383 Updates #34094 Fixes #34497 Fixes #34215 Change-Id: If37dc422e973eba13f3a3aeb68bc7b96e2d7f73d Reviewed-on: https://go-review.googlesource.com/c/go/+/197059 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> (cherry picked from commit a3426f2) Reviewed-on: https://go-review.googlesource.com/c/go/+/197063
|
This should be working using |
|
Change https://golang.org/cl/199839 mentions this issue: |
In CL 197059, I suppressed errors if the target package was already found. However, that does not cover the case of passing a '/v2' module path to 'go get' when the module does not contain a package at its root. This CL is a minimal fix for that case, intended to be backportable to 1.13. (Longer term, I intend to rework the version-validation check to treat all mismatched paths as ErrNotExist.) Fixes #34746 Updates #34383 Change-Id: Ia963c2ea00fae424812b8f46a4d6c2c668252147 Reviewed-on: https://go-review.googlesource.com/c/go/+/199839 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
What version of Go are you using (
go version)?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?
We were upgrading a library (
github.com/segmentio/events) to match proper major version module semantics (we already had some v2 release tags from before modules), and we kept running into the following when trying togo getthe module.What did you expect to see?
We expected to see the module fetched without an error.
What did you see instead?
We're aware that the other v2 tags are invalid: that is they don't have a correct go.mod file.
When we remove the
v2branch from the repository,go getworks again without issues. We're skipping the module proxy and doing this with a clean modules cache. We expect that the error is a bit more clear at the very least. At the best, it ignores thev2branch entirely and just uses the tag specified.We're leaving the
v2branch in tact for now so that others can test and debug this issue.Also interestingly, doing
go getwithout specifying the exact tag works fine:The text was updated successfully, but these errors were encountered: