proposal: cmd/go: change GO111MODULE=auto to have GO111MODULE=on behavior

[matloob]

cc @golang/go-command

When modules were introduced our plan was initially to remove GOPATH mode behavior, but we decided to keep GOPATH mode indefinitely (#60915). This allows users to keep building very old Go code with new toolchains. While this isn't strictly required by our compatibility promises, it is certainly in the spirit of them. Given that we're keeping GOPATH mode indefinitely it would be helpful to simplify the decision of when they're run.

#60915 proposed to

Commit to preserving the ability to build GOPATH-layout source trees when GO111MODULE=off, indefinitely.

but it didn't directly mention GO111MODULE=auto mode itself. This proposal would make it so that GO111MODULE=auto mode is essentially "removed" by changing it to have the same behavior as GO111MODULE=on. This change would make it easier for the go command to know at startup time which mode it was operating in and would allow us to make some simplifications: for example, the toolchain selection code wouldn't need to do the check if it's in a module or workspace to determine its behavior, and knowing at startup time which mode we're in would allow us to do some more cleanups.

We've changed the meaning of GO111MODULE=auto before so that we wouldn't automatically enter GOPATH mode when we were in $GOPATH/src (#31857), so a change like this isn't totally without precedent (though of course it is far more broad).

[gabyhelp]

Related Issues

• cmd/go: default to GO111MODULE=auto (with changes) for Go 1.13 #31857 (closed)
• cmd/go: change default of GO111MODULE from 'auto' to 'on' #30228 (closed)
• cmd/go: default to GO111MODULE=on #41330 (closed)
• proposal: cmd/go: module semantics in $GOPATH/src #26377 (closed)
• cmd/go: preserve basic GOPATH mode indefinitely #60915 (closed)
• go/build: doesn't implement new GO111MODULE=auto logic for 1.13 #32799 (closed)
• proposal: cmd/go: discover module from package being built #68059 (closed)
• Now that Go Modules have been default for a long time, assume GO111MODULE=on by default. #44216 (closed)
• build: remove GO111MODULE=auto hack before shipping Go 1.13 #30759 (closed)

Related Code Changes

• cmd/go: default to GO111MODULE=auto and make it trigger in GOPATH/src

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[matloob]

The Go Command Working Group (@golang/go-command) is unanimously in favor of this proposal and supports moving it forward to the proposal committee to move through the proposal process

[thepudds]

Hi @rittneje, I think I've seen you mention on other issues that you and your colleagues still use GOPATH?

I'm curious if you purposefully use GO111MODULE=auto, and if so, what are your current use cases for that (vs. if you set GO111MODULE=off vs. GO111MODULE=on as needed).

[rittneje]

@thepudds Yes, I believe most of our devs set it to auto globally to be able to easily switch between our older repos that are in GOPATH mode and our newer repos that are in module mode. (At least, that is what is in our setup guides and what I have on my dev machine.) Otherwise, we'd have to remember to switch back and forth in the terminal depending on what we are working on.

[glycerine]

I'm not sure I understand the rationale or consequences here, but it sounds like this makes it difficult to build old code, and then change to a different project and build new code, without also having to reset your environemnt to change GO111MODULE from on to off; it sounds like this removes the auto feature entirely. Given this is a useful feature, one that I use, it seems rather damaging to very common workflows.

[matloob]

@glycerine @rittneje I'm interested in what your requirements with GOPATH workspaces are: how often are you building GOPATH projects and switching between GOPATH mode and using modules? Do you have plans to migrate your GOPATH projects to module mode, and if not, why not? Is there anything we could do to remove blockers to migration? We anticipated that go developers would want to build GOPATH projects that are no longer actively developed, but we had hoped that significant actively developed projects would be able to migrate to module mode.

Even so, if we do end up making this change we'd want to find ways to reduce the impact on people who are actively developing both GOPATH and modules projects. We'd have to think about how to do that, but to throw out one idea, we could write a tool wrapping the go command that looks for a module directory and sets GO111MODULE to on or off depending on whether one was found similar to the GO111MODULE=auto logic.

[rittneje]

Our newer repos are all using modules, but our older repos, which are still actively developed, are still in GOPATH mode. (Some have made more progress towards module mode than others.)

Getting them migrated has been on the backlog for a long time. Unfortunately, it has been difficult getting that work prioritized. First because the dependency management is different, as they currently just use git submodules of forks/mirrors. And second, because we would have to change basically every file to fix all the import paths, and that is rather difficult to do when the repo is under active development without instituting a merge freeze.

Just spitballing, but would it help at all if the toolchain did something like: "if the cwd is under $GOPATH, and $GOPATH/go.env exists, apply it"? Then our older repos could put GO111MODULE=off and even GOTOOLCHAIN in there.

[qiulaidongfeng]

I use GOPATH to run simple code about a dozen times a year, for these reasons

1. Reproducing some interesting issues on my device often helps me better understand the std. Here are some examples text/template: bad format string for range-over-int error #69708
   cmd/go: test failure in TestScript/list_pkgconfig_error from commit 906338f82fc6641e834964def3199ac25df93e94 onward #69651 reflect: Value.Seq|Seq2 documentation and unexported value #74377 (comment)
2. Try out some new features and see if they are helpful to me by replicating the minimum benchmarks of some of my common cases，example sort: slices.Sort is slightly slower than sort.Strings on some sorted inputs #60777 iter: new package for iterators #61897 (comment)
3. Write some very small tools, such as A learning CLI that reads files and randomly selects words or I said it in cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658 (comment)

I have no plans to switch to using modules, mainly for developer experience. Having to run go mod init for each of these cases every time would be too cumbersome.

Just spitballing, but would it help at all if the toolchain did something like: "if the cwd is under $GOPATH, and $GOPATH/go.env exists, apply it"? Then our older repos could put GOTOOLCHAIN=off in there.

If there were a way to set GOTOOLCHAIN=off for a specific directory, that would be really nice—I could then stop needing GOTOOLCHAIN=auto.