cmd/go: default to GO111MODULE=auto (with changes) for Go 1.13 #31857
Comments
|
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 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 Two other obvious alternatives:
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 |
bcmills
added
the
NeedsDecision
|
Are there scenarios in which having "auto" have different semantics across toolchains would be an annoyance? |
Yes.
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. |
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. |
|
I'll be that one guy who thinks we're not ready yet for Go modules adaptation but still wants to see However, the change to the default auto mode, checking the existence of a Overall, LGTM. |
|
Change https://golang.org/cl/176580 mentions this issue: |
|
I think there is one other case where Namely, if the current command is a |
If we look at the issues in the past releases that are related to go command that involved modules, its usually mention or ask about the value of GO111MODULE, either in separate line or in separate comment. There are quite long time range before GO111MODULE will be removed (unused). The next release is still default to auto [1], and until Go 1.13 unsupported (two releases after that) there is about one and half years after that. Since the change is not that big (one line) [2], maybe temporary adding it to "go env" give more clarity and benefit in issue reporting rather than not. [1] #31857 Fixes #29656 Change-Id: I609ad6664774018e4f4147ec6158485172968e16 Reviewed-on: https://go-review.googlesource.com/c/go/+/176837 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Is there a place (or a GitHub label) to track the issues that are standing between GO111MODULE being ON by default or not? |
|
@marwan-at-work We haven't put together a list of 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. |
This reverts commit d5b8540. It turns out that this variable is somewhat necessary, even with Go 1.12, because if a CI system clones Mutagen into $GOPATH/src (which happens on Travis), and GO111MODULE is unset or set to "auto" (which is the default and also explicitly done on Travis), then module support is disabled. Until GO111MODULE=on is the default, let's continue to set this, even on AppVeyor (where it may not be necessary since we don't clone into %GOPATH%/src). Looking forward, it looks like Go 1.13 may not make GO111MODULE=on the default after all, but it looks like it may remove the disable-if-in-$GOPATH/src behavior, so we may be able to get rid of this setting at that point. See golang/go#31857 for more information.
|
go mod init works without a go.mod. 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. |
@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 |
|
Looks like we also need to update the documentation for the new behavior. I'll do that today. |
|
Change https://golang.org/cl/180197 mentions this issue: |
|
Change https://golang.org/cl/183922 mentions this issue: |
Updates #31857 Change-Id: Id0dc66246f768a2c730c67cd7a4a7830547f22a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/183922 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Katie Hockman <katie@golang.org>
dmitshur
added
NeedsFix
|
I noticed that the logic that handles GO111MODULE=auto in |
|
I ran this command |
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 anditself 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?
The text was updated successfully, but these errors were encountered: