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: get does not understand go-import meta tag with mod method by default #40883

darkfeline opened this issue Aug 19, 2020 · 5 comments


Copy link

@darkfeline darkfeline commented Aug 19, 2020

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

What did you do?

Run go get outside of module dir.

What did you expect to see?


What did you see instead?

package unrecognized import path "": parse no go-import meta tags ()

Note that 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).

Copy link

@jayconrod jayconrod commented Aug 19, 2020

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.

@jayconrod jayconrod added this to the Unplanned milestone Aug 19, 2020
Copy link
Contributor Author

@darkfeline darkfeline commented Aug 20, 2020

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.

Copy link

@jayconrod jayconrod commented Aug 20, 2020

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 from any directory without setting GO111MODULE explicitly.

Copy link

@dmitshur dmitshur commented Sep 19, 2020

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.

Copy link

@jayconrod jayconrod commented Sep 21, 2020

Right, let's close this then.

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

go install works now, regardless of the current working directory.

@jayconrod jayconrod closed this Sep 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.