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