cmd/go: add minimal support for vgo transition

[rsc]

Quoting #24301 (comment):

Define “new” code as code with a go.mod file in the same directory or a parent directory. The old go get must continue to download code exactly as it always has. I propose that the “go build” step adjust its handling of imports in “new” code. Specifically, if an import in new code says x/y/v2/z but x/y/v2/z does not exist and x/y/go.mod says “module x/y/v2”, then go build will read the import as x/y/z instead. We would push this update as a point release for Go 1.9 and Go 1.10.

[AlexRouSg]

Did you just dupe yourself? #24916

[gopherbot]

Change https://golang.org/cl/109340 mentions this issue: cmd/go: add minimal module-awareness for legacy operation

[bcmills]

@gopherbot, please make this a backport candidate for Go 1.9 and 1.10.

[gopherbot]

Backport issue(s) opened: #25139 (for 1.10), #25140 (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.

[joshuarubin]

There's a bit of a chicken and egg situation with this. The sooner that point releases for Go 1.9 and 1.10 are released with this support, the easier it will be to start adopting vgo. Releasing those then introduces a behavior that must be supported according to https://golang.org/doc/go1compat. If something about the vgo proposal affected by this change is modified, or it is dropped entirely, then we are saddled with unused or incorrect behavior that can't be removed.

As far as I am concerned, this support can't be added soon enough. Waiting for a full release of vgo (in Go 1.12) before adding this support would make testing vgo (now and in Go 1.11) in a backwards compatible way impossible.

[orivej]

The old go get must continue to download code exactly as it always has. I propose that the “go build” step adjust its handling of imports in “new” code. Specifically, if an import in new code says x/y/v2/z but x/y/v2/z does not exist and x/y/go.mod says “module x/y/v2”, then go build will read the import as x/y/z instead.

What would this achieve? The old "go get" (even "go get -d", "download only") will fail to process a package with import "x/y/v2/z" with the error cannot find package "x/y/v2/z" in any of: …, and "go build" will not be invoked.

[rsc]

By "download code exactly as it has" I mean that it will decide which repositories and which commits to use as before. Once downloaded the interpretation of that code is handled by the logic in "go build" that we will change.

[gopherbot]

Change https://golang.org/cl/114500 mentions this issue: [release-branch.go1.10] cmd/go: add minimal module-awareness for legacy operation