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: add minimal support for vgo transition #25069

Closed
rsc opened this Issue Apr 25, 2018 · 10 comments

Comments

Projects
None yet
7 participants
@rsc
Contributor

rsc commented Apr 25, 2018

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

This comment has been minimized.

Contributor

AlexRouSg commented Apr 25, 2018

Did you just dupe yourself? #24916

@gopherbot

This comment has been minimized.

gopherbot commented Apr 25, 2018

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

@bcmills

This comment has been minimized.

Member

bcmills commented Apr 27, 2018

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

@gopherbot

This comment has been minimized.

gopherbot commented Apr 27, 2018

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

This comment has been minimized.

Contributor

joshuarubin commented May 10, 2018

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

This comment has been minimized.

orivej commented May 15, 2018

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

This comment has been minimized.

Contributor

rsc commented May 25, 2018

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

This comment has been minimized.

gopherbot commented May 25, 2018

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

@gopherbot gopherbot closed this in d4e2128 May 30, 2018

gopherbot pushed a commit that referenced this issue May 30, 2018

[release-branch.go1.10] cmd/go: add minimal module-awareness for lega…
…cy operation

We want authors to be able to publish code that works with both
the current standard go command and the planned new go command
support for modules. If authors have tagged their code v2 or later,
semantic import versioning means the import paths must include a
v2 path element after the path prefix naming the module.
One option for making this convention compatible with original go get
is to move code into a v2 subdirectory of the root.
That makes sense for some authors, but many authors would prefer
not to move all the code into a v2 subdirectory for a transition and
then move it back up once we everyone has a module-aware go command.

Instead, this CL teaches the old (non-module-aware) go command
a tiny amount about modules and their import paths, to expand
the options for authors who want to publish compatible packages.
If an author has a v2 of a package, say my/thing/v2/sub/pkg,
in the my/thing repo's sub/pkg subdirectory (no v2 in the file system path),
then old go get continues to import that package as my/thing/sub/pkg.
But when go get is processing code in any module (code in a tree with
a go.mod file) and encounters a path like my/thing/v2/sub/pkg,
it will check to see if my/thing/go.mod says "module my/thing/v2".
If so, the go command will read the import my/thing/v2/sub/pkg
as if it said my/thing/sub/pkg, which is the correct "old" import path
for the package in question.

This CL will be back-ported to Go 1.10 and Go 1.9 as well.

Once users have updated to the latest Go point releases containing
this new logic, authors will be able to update to using modules
within their own repos, including using semantic import paths
with vN path elements, and old go get will still be able to consume
those repositories.

This CL also makes "go get" ignore meta go-import lines using
the new "mod" VCS type. This allows a package to specify both
a "mod" type and a "git" type, to present more efficient module
access to module-aware go but still present a Git repo to the old
"go get".

Fixes #24751.
Fixes #25069.

Backport fixes #25139.

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

This comment has been minimized.

gopherbot commented May 30, 2018

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

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

[release-branch.go1.9] cmd/go: add minimal module-awareness for legac…
…y operation

We want authors to be able to publish code that works with both
the current standard go command and the planned new go command
support for modules. If authors have tagged their code v2 or later,
semantic import versioning means the import paths must include a
v2 path element after the path prefix naming the module.
One option for making this convention compatible with original go get
is to move code into a v2 subdirectory of the root.
That makes sense for some authors, but many authors would prefer
not to move all the code into a v2 subdirectory for a transition and
then move it back up once we everyone has a module-aware go command.

Instead, this CL teaches the old (non-module-aware) go command
a tiny amount about modules and their import paths, to expand
the options for authors who want to publish compatible packages.
If an author has a v2 of a package, say my/thing/v2/sub/pkg,
in the my/thing repo's sub/pkg subdirectory (no v2 in the file system path),
then old go get continues to import that package as my/thing/sub/pkg.
But when go get is processing code in any module (code in a tree with
a go.mod file) and encounters a path like my/thing/v2/sub/pkg,
it will check to see if my/thing/go.mod says "module my/thing/v2".
If so, the go command will read the import my/thing/v2/sub/pkg
as if it said my/thing/sub/pkg, which is the correct "old" import path
for the package in question.

This CL will be back-ported to Go 1.10 and Go 1.9 as well.

Once users have updated to the latest Go point releases containing
this new logic, authors will be able to update to using modules
within their own repos, including using semantic import paths
with vN path elements, and old go get will still be able to consume
those repositories.

This CL also makes "go get" ignore meta go-import lines using
the new "mod" VCS type. This allows a package to specify both
a "mod" type and a "git" type, to present more efficient module
access to module-aware go but still present a Git repo to the old
"go get".

Fixes #24751.
Fixes #25069.

This backport to Go 1.9 also had to pick up p.Internal.RawImports
from CL 74750 and CL 74356 and use it to prepare an updated
set of -importmap arguments for the compiler. (The old code only
understood vendor-related rewriting of import paths.)

Backport fixes #25140.

Change-Id: I378955613a0d63834d4f50f121f4db7e4d87dc0a
Reviewed-on: https://go-review.googlesource.com/115298
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@marwan-at-work

This comment has been minimized.

Contributor

marwan-at-work commented Aug 26, 2018

I wrote a CLI tool that hopefully helps with this transition in the community: https://github.com/marwan-at-work/mod

If you have, or know of, a Go package that is tagged >= 2 but does not use Semantic Import Versioning, feel free to use this tool and let me know if it works/doesn't.

I think eventually this should be part of the mod sub command itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment