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.

Comment From: gabyhelp

Similar Issues

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

Comment From: bjorndm

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

Comment From: rittneje

@bjorndm What backwards compatibility reasons?

Comment From: 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.

Comment From: 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.