Navigation Menu

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

Jump to bottom

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

Closed
darkfeline opened this issue Aug 19, 2020 · 5 comments
Closed

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
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@darkfeline
Copy link
Contributor

darkfeline commented Aug 19, 2020 •
edited

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).
@darkfeline darkfeline mentioned this issue Aug 19, 2020
Closed
@jayconrod
Copy link
Contributor

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 the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Aug 19, 2020
@jayconrod jayconrod added this to the Unplanned milestone Aug 19, 2020
@darkfeline
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

dmitshur commented Sep 19, 2020 •
edited

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
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Sep 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@jayconrod @darkfeline @dmitshur @gopherbot