cmd/go: get does not understand go-import meta tag with mod method by default

[darkfeline]

What version of Go are you using (go version)?

$ go version
go version go1.15 linux/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""

What did you do?

Run go get go.felesatra.moe/animanager outside of module dir.

What did you expect to see?

Success

What did you see instead?

package go.felesatra.moe/animanager: unrecognized import path "go.felesatra.moe/animanager": parse https://go.felesatra.moe/animanager?go-get=1: no go-import meta tags ()

Note that go.felesatra.moe/animanager does include a go-import meta tag, but using mod instead of a vcs value.

It's arguable whether this is a bug. Strictly speaking, go get is behaving as documented:

For more fine-grained control, the go command continues to respect
a temporary environment variable, GO111MODULE, which can be set to one
of three string values: off, on, or auto (the default).
If GO111MODULE=on, then the go command requires the use of modules,
never consulting GOPATH. We refer to this as the command
being module-aware or running in "module-aware mode".
If GO111MODULE=off, then the go command never uses
module support. Instead it looks in vendor directories and GOPATH
to find dependencies; we now refer to this as "GOPATH mode."
If GO111MODULE=auto or is unset, then the go command enables or disables
module support based on the current directory.
Module support is enabled only when the current directory contains a
go.mod file or is below a directory containing a go.mod file.

So running go get outside of a module dir has module support disabled, so it does not support mod meta tags.

However, practically speaking it's not desirable that you can't go get a program if it uses a mod meta tag, since end users don't care about that (it works if you explicitly set GO111MODULE=on, naturally).

[jayconrod]

Sorry, this is unlikely to be implemented.

Since GO111MODULE is not set, when go get is invoked outside a module, it runs in GOPATH mode. Downloading modules in GOPATH mode is unlikely to be supported. Downloading and extracting them would be easy enough, but there are a ton of edge cases to consider, for example, with overlapping modules at different versions.

In general, we aren't actively developing GOPATH mode anymore, and our intent is to eventually change the default of GO111MODULE to on.

[darkfeline]

There is an alternative solution, which is to modify GO111MODULE=auto to use the modules logic instead of GOPATH when go get is invoked outside a module. Disclaimer: I haven't thought about any adverse implications of this.

[jayconrod]

We'd like to change the default of GO111MODULE to on eventually, but we need to ensure the module UX is fully polished first.

Incidentally, if you're mainly using go get to install executables (as opposed to downloading sources into GOPATH), #40276 should help. You'd be able to run go install go.felesatra.moe/animanager@latest from any directory without setting GO111MODULE explicitly.

[dmitshur]

If I understand this issue correctly (also based on reading darkfeline/animanager-go#1), this issue doesn't exist in module mode, only in GOPATH mode (including when it's chosen through GO111MODULE=auto).

As a consequence, this will be resolved indirectly via #41330.

[jayconrod]

Right, let's close this then.

GO111MODULE=on now defaults to on, so you'll be able to run go get go.felesatra.moe/animanager outside of a module without setting GO111MODULE=on.

go install go.felesatra.moe/animanager@latest works now, regardless of the current working directory.