cmd/go: default to GO111MODULE=auto (with changes) for Go 1.13

[rsc]

We have set GO111MODULE=on by default in the Go 1.13 development branch, but we have reached the development freeze and there are still a number of important outstanding issues we have not had time to address, including making the transition for GOPATH users as smooth as possible in all the tools they use.

Based on discussion with @andybons, @ianthehat, @bcmills, @jayconrod, and others, I suggest we ship Go 1.13 with the GO111MODULE default set back to “auto”, but with the GOPATH/src restriction removed. Compared to Go 1.12 the definition of GO111MODULE=auto would change to:

“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 is outside GOPATH/src and itself contains a go.mod file or is below a directory containing a go.mod file.”

That is, “is outside GOPATH/src” would be removed.

The effect would be that in Go 1.13, if you run go commands in a directory tree where someone has created a go.mod (that is, either you put the go.mod there, or the project you are contributing to has decided to switch to module-based development), then you get module mode, regardless of whether you happened to check it out inside or outside GOPATH/src. The “outside GOPATH/src” restriction has been the number one complaint about the existing automatic mode. Fixing it would help make the go command work better for all the people who are ready for modules, without turning it on for everyone prematurely.

Put another way, in Go 1.12 there were two steps to adopting modules for your project: (1) create a go.mod and (2) move your code. The new rule would cut out the difficult step (2) and leave the easy step (1). Module mode for module code, no matter where it is.

Thoughts?

[thepudds]

This makes sense to me personally. I think it is better to take the time needed, and that seems to be a common sentiment within the broader community. (It seems people frequently express a desire for the transition to modules to be over, but at the same time people usually seem to be supportive of avoiding rushing it in order to end up with a good result and smooth transition).

And just to be explicit, under this proposal if you are in GOPATH and in a directory with a go.mod with GO111MODULE=auto, GOPATH would not be consulted to find dependencies, correct?

If so, that is slightly awkward as default behavior for someone who is not really ready to adopt modules, especially if they are inside someone else's module in their GOPATH ("Why is GOPATH being ignored for the dependencies?", "Why are the dependencies being downloaded?"), but they have the option of GO111MODULE=off, or to start ramping up on how to work with modules. (edit: And again just to be explicit – of course the more common case is someone being inside their own code, where the new behavior would follow whether or not their own code has a go.mod in GOPATH, which is friendlier behavior overall).

Two other obvious alternatives:

1. change the default back to auto, but keep the definition as is.
2. introduce a fourth option for GO111MODULE.

Neither of those seem more appealing than this proposal. Part of what is nice about this proposal is it smooths out adoption for someone who is ready for modules, while also providing more time for the ecosystem to adapt before GO111MODULE=on is the default.

[josharian]

Are there scenarios in which having "auto" have different semantics across toolchains would be an annoyance?

[rsc]

And just to be explicit, under this proposal if you are in GOPATH and in a directory with a go.mod with GO111MODULE=auto, GOPATH would not be consulted to find dependencies, correct?

Yes.

If so, that is slightly awkward as default behavior for someone who is not really ready to adopt modules, especially if they are inside someone else's module in their GOPATH

Yes, and fear of this awkward behavior was the rationale for not adopting this meaning of auto originally. But I think the balance has shifted, where before we were willing to make modules noticeably harder to adopt, in order to avoid even the very unlikely possibility of confusing GOPATH users. Now we are willing to trade this (still unlikely) possibility for making modules easier to work with and smoothing out the eventual transition to modules all the time.

[rsc]

Are there scenarios in which having "auto" have different semantics across toolchains would be an annoyance?

If you replace "auto" with "the default behavior of the go command", there was a change from Go 1.10 to Go 1.11 (modules "off" to "auto"), and there will probably be a change from Go 1.13 to Go 1.14 ("auto" to "on"). A (comparatively minor) change from Go 1.12 to Go 1.13 ("auto1" to "auto2") seems OK.

[akyoto]

I'll be that one guy who thinks we're not ready yet for Go modules adaptation but still wants to see GO111MODULE=on by default in 1.13 to speed up the support of Go modules in developer tools across the open source ecosystem.

However, the change to the default auto mode, checking the existence of a go.mod file in the working directory and not being forced to move the directory, seems like a good compromise to me.

Overall, LGTM.

[gopherbot]

Change https://golang.org/cl/176580 mentions this issue: cmd/go: default to GO111MODULE=auto and make it trigger in GOPATH/src

[bcmills]

I think there is one other case where GO111MODULE=auto should enable module mode for 1.13.

Namely, if the current command is a mod subcommand such as go mod download, then auto should activate module mode even without a go.mod file (see #27783).

[marwan-at-work]

there are still a number of important outstanding issues we have not had time to address

Is there a place (or a GitHub label) to track the issues that are standing between GO111MODULE being ON by default or not?

[jayconrod]

@marwan-at-work We haven't put together a list of GO111MODULE=on-by-default blocking issues yet. I expect we'll have something like that when the 1.14 development cycle opens.

Personally, I think there are only a handful of issues that absolutely must be fixed first, but there are a lot of smaller bugs and annoyances that add up to a suboptimal experience. I don't think we'll be able to fix all of them before 1.14, but fixing many of them will make the 1.14 experience much better.

[rsc]

go mod init works without a go.mod.
It would be fine to make go mod download work without a go.mod too (we almost did that for Go 1.12), but of course all the proxies using Go 1.12's go mod download already deal with that.

The other commands, like mod graph, should end up in modload.die, probably because they called modload.ModRoot. They should not require special-case errors. It looks like modload.InitMod should call die if GO111MODULE=auto.

[marwan-at-work]

It would be fine to make go mod download work without a go.mod too (we almost did that for Go 1.12)

@rsc I ran a quick test and this already works for Go 1.12, Not sure if I'm missing an edge case here? Of course we need GO111MODULE=on otherwise it wouldn't work, which might be okay to remove in 1.13 if that's what you originally meant (and what @bcmills suggested above). Thanks!

[bcmills]

Looks like we also need to update the documentation for the new behavior. I'll do that today.

[gopherbot]

Change https://golang.org/cl/180197 mentions this issue: cmd/go: document GO111MODULE=auto behavior for Go 1.13

[gopherbot]

Change https://golang.org/cl/183922 mentions this issue: doc/go1.13: describe the change in behavior of GO111MODULE=auto

[dmitshur]

I noticed that the logic that handles GO111MODULE=auto in go/build hasn't been updated either. I filed #32799 with a NeedsDecision label for it.

[VictorUUsoro]

I ran this command
export GO111MODULE="on"
It worked for me