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: default to GO111MODULE=auto (with changes) for Go 1.13 #31857

Closed
rsc opened this issue May 6, 2019 · 16 comments
Closed

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

rsc opened this issue May 6, 2019 · 16 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented May 6, 2019

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?

@rsc rsc added this to the Go1.13 milestone May 6, 2019
@thepudds
Copy link
Contributor

thepudds commented May 6, 2019

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.

@bcmills bcmills added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 6, 2019
@josharian
Copy link
Contributor

josharian commented May 6, 2019

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

@rsc
Copy link
Contributor Author

rsc commented May 6, 2019

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

rsc commented May 6, 2019

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

akyoto commented May 7, 2019

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

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

@bcmills
Copy link
Contributor

bcmills commented May 17, 2019

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

@bcmills bcmills reopened this May 17, 2019
gopherbot pushed a commit that referenced this issue May 20, 2019
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>
@marwan-at-work
Copy link
Contributor

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

@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.

xenoscopic added a commit to mutagen-io/mutagen that referenced this issue May 23, 2019
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.
@rsc
Copy link
Contributor Author

rsc commented May 28, 2019

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

marwan-at-work commented May 28, 2019

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

bcmills commented Jun 3, 2019

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

@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Jun 26, 2019
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 dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jun 27, 2019
@dmitshur
Copy link
Contributor

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

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

10 participants