Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go get github.com/rsc/vgotest5 fails #25687

Closed
rsc opened this issue Jun 1, 2018 · 11 comments

Comments

Projects
None yet
4 participants
@rsc
Copy link
Contributor

commented Jun 1, 2018

go get github.com/rsc/vgotest5 should work with the latest Go 1.9 release branch yet does not. rsc to fix.

/cc @andybons

@rsc rsc added this to the Go1.9.7 milestone Jun 1, 2018

@rsc rsc self-assigned this Jun 1, 2018

@rsc rsc modified the milestones: Go1.9.7, Go1.11 Jun 1, 2018

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2018

@gopherbot backport Go 1.9 Go 1.10

This is actually present everywhere; you just have to start with nothing in GOPATH and ask for vgotest5 directly (without doing vgotest4 first).

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2018

@gopherbot PLEASE backport Go 1.9 Go 1.10

@gopherbot

This comment has been minimized.

Copy link

commented Jun 1, 2018

Backport issue(s) opened: #25690 (for 1.10), #25691 (for 1.9).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2018

(Seriously? We've gone full-on Jurassic Park? What purpose does this serve?)

@andybons

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

When the robot uprising inevitably occurs we can at least say we were polite to their ancestors.

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2018

Getting off-topic for this issue but the best technical rationale I can see is that having an indicator word beyond the @-reference avoids false triggering the bot, so that it wouldn't trigger on someone saying "why did (AT)gopherbot backport that CL?". Otherwise you're just playing simon says for no good reason.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 1, 2018

Change https://golang.org/cl/115797 mentions this issue: cmd/go: fix 'go get' compatibility for direct download of vgo-aware module

@andybons

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

@FiloSottile for the gopherbot semantics. If we want to continue this conversation let’s start a new issue.

@FiloSottile

This comment has been minimized.

Copy link
Member

commented Jun 2, 2018

I indeed came up with it as a false positive mitigation for such a high-touch action with cases like you mentioned in mind, but I'll admit I did not consider alternatives because I do like the idea of having to be nice in comments, even to the bot.

Opened #25700 for documenting @gopherbot actions.

@gopherbot gopherbot closed this in 446d76e Jun 4, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Jun 4, 2018

Change https://golang.org/cl/116175 mentions this issue: [release-branch.go1.9] cmd/go: fix 'go get' compatibility for direct download of vgo-aware module

@gopherbot

This comment has been minimized.

Copy link

commented Jun 4, 2018

Change https://golang.org/cl/116176 mentions this issue: [release-branch.go1.10] cmd/go: fix 'go get' compatibility for direct download of vgo-aware module

gopherbot pushed a commit that referenced this issue Jun 4, 2018

[release-branch.go1.10] cmd/go: fix 'go get' compatibility for direct…
… download of vgo-aware module

CL 109340 added “minimal module-awareness for legacy operation.”
One part of that is reinterpreting imports inside code trees with go.mod files
as using semantic import versioning, and converting them back to
legacy import paths by stripping the major version element
(for example, interpreting import "x.com/foo/v2/bar" as import "x.com/foo/bar").
This rewrite was not being applied during "go get", with the effect that once
you had the target code downloaded already, everything was fine,
but it didn't download and build successfully the first time.

Fixes #25687.
Cherry-pick fixes #25690.

Change-Id: I3e122efdc8fd9a0a4e66f5aa3e6a99f90c7df779
Reviewed-on: https://go-review.googlesource.com/115797
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/116176

gopherbot pushed a commit that referenced this issue Jun 4, 2018

[release-branch.go1.9] cmd/go: fix 'go get' compatibility for direct …
…download of vgo-aware module

CL 109340 added “minimal module-awareness for legacy operation.”
One part of that is reinterpreting imports inside code trees with go.mod files
as using semantic import versioning, and converting them back to
legacy import paths by stripping the major version element
(for example, interpreting import "x.com/foo/v2/bar" as import "x.com/foo/bar").
This rewrite was not being applied during "go get", with the effect that once
you had the target code downloaded already, everything was fine,
but it didn't download and build successfully the first time.

Fixes #25687.
Cherry-pick fixes #25691.

Change-Id: I3e122efdc8fd9a0a4e66f5aa3e6a99f90c7df779
Reviewed-on: https://go-review.googlesource.com/115797
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/116175
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.