We're porting a lot of tools to support modules, and most of them need to know whether modules are enabled to turn on the newer, slower, potentially buggier code path. Running go env GOMOD takes about 10ms, which is not negligible for an interactive command like godef or guru. The algorithm for determining if modules are on is just simple enough to tempt people to roll their own. In fact, there's already a second implementation in go/build:
|
switch os.Getenv("GO111MODULE") { |
This is unfortunate, especially since the algorithm changed in http://golang.org/cl/148517. (Maybe not in a way that matters for go/build? Not sure.)
I think it'd be helpful to have a standalone internal package that implemented this functionality that could be used for go env, go/build, and copied into x/tools for other tools to use.
@bcmills @jayconrod @ianthehat
We're porting a lot of tools to support modules, and most of them need to know whether modules are enabled to turn on the newer, slower, potentially buggier code path. Running
go env GOMODtakes about 10ms, which is not negligible for an interactive command likegodeforguru. The algorithm for determining if modules are on is just simple enough to tempt people to roll their own. In fact, there's already a second implementation ingo/build:go/src/go/build/build.go
Line 977 in 429bae7
This is unfortunate, especially since the algorithm changed in http://golang.org/cl/148517. (Maybe not in a way that matters for go/build? Not sure.)
I think it'd be helpful to have a standalone internal package that implemented this functionality that could be used for
go env,go/build, and copied into x/tools for other tools to use.@bcmills @jayconrod @ianthehat