proposal: cmd/go: discover module from package being built

[rittneje]

Proposal Details

I am filing this proposal as a followup to #68043.

Currently the go command discovers the module based upon the working directory it is executed from. This results in confusing and unexpected behavior when you do for example go build ./path/to/module/package, since in that case it will either fail (if GO111MODULE=on) or fall back to non-module mode (if GO111MODULE=auto). In the latter case, this also means it will build with the wrong DefaultGODEBUG.

I propose that instead of discovering the module based on the current working directory, the go command instead discovers it based upon the location of the package you are building. So in the example of go build ./path/to/module/package, it will use the module rooted at ./path/to/module, assuming that ./path/to/module/go.mod exists.

[gabyhelp]

Similar Issues

• cmd/go: Module mode doesn't turn on automatically while build upon relative path #34043
• compiler detects module based on current working directory #68043
• cmd/go: module mode doesn't work without go.mod #26994
• proposal: cmd/go: module semantics in $GOPATH/src #26377
• cmd/go: improve error when a package exists in the filesystem but is in a different module #30590
• cmd/go: [modules + integration] go mod discover, discover a set of unpacked modules within a directory #31299
• cmd/go: 'cannot find module for path' when importing from subdirectories #26645
• go/build: doesn't implement new GO111MODULE=auto logic for 1.13 #32799
• go/build: resolve package in GOPATH when GO111MODULE=on outside module #34669
• cmd/go: auto-find module from package import #43493

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

[bjorndm]

This will be difficult for backwards compatibility reasons. A go.work file might help, or perhaps a new environment variable could be added.

[rittneje]

@bjorndm What backwards compatibility reasons?

[matloob]

@rittneje This would be a big change from the behavior of the Go command users are familiar with and it would introduce a lot of confusion.

While this might seem appealing if you only look at relative package paths, in general for a full package path we wouldn't easily be able to figure out what module it belongs to. Also, users often pass in the paths to packages in dependency modules. In those cases they want to build/test/list the package as a module dependency rather than from its module.

[rittneje]

@matloob I think it is very unfortunate that you won't consider this change. The current behavior is clearly incorrect, and easily leads to production issues that may go unnoticed.