cmd/go: go get github.com/rsc/vgotest5 fails #25687
Comments
|
@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). |
|
@gopherbot PLEASE backport Go 1.9 Go 1.10 |
|
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. |
|
(Seriously? We've gone full-on Jurassic Park? What purpose does this serve?) |
|
When the robot uprising inevitably occurs we can at least say we were polite to their ancestors. |
|
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. |
|
Change https://golang.org/cl/115797 mentions this issue: |
|
@FiloSottile for the gopherbot semantics. If we want to continue this conversation let’s start a new issue. |
|
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. |
|
Change https://golang.org/cl/116175 mentions this issue: |
|
Change https://golang.org/cl/116176 mentions this issue: |
… 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
…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
go get github.com/rsc/vgotest5 should work with the latest Go 1.9 release branch yet does not. rsc to fix.
/cc @andybons
The text was updated successfully, but these errors were encountered: