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

go/build: Default does not honor go env -w GOPATH #39838

Open
heschi opened this issue Jun 24, 2020 · 4 comments
Open

go/build: Default does not honor go env -w GOPATH #39838

heschi opened this issue Jun 24, 2020 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@heschi
Copy link
Contributor

heschi commented Jun 24, 2020

go/build has no logic for reading the GOENV file, so it will ignore any GOPATH setting there.

go/src/go/build/build.go

Lines 275 to 292 in 7eb5941

func defaultGOPATH() string {
env := "HOME"
if runtime.GOOS == "windows" {
env = "USERPROFILE"
} else if runtime.GOOS == "plan9" {
env = "home"
}
if home := os.Getenv(env); home != "" {
def := filepath.Join(home, "go")
if filepath.Clean(def) == filepath.Clean(runtime.GOROOT()) {
// Don't set the default GOPATH to GOROOT,
// as that will trigger warnings from the go tool.
return ""
}
return def
}
return ""
}

@gopherbot
Copy link

Change https://golang.org/cl/239754 mentions this issue: all: rework goimports environment, support GOMODCACHE

gopherbot pushed a commit to golang/tools that referenced this issue Jun 25, 2020
This CL got away from me a little.

For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.

There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.

Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.

Fixes golang/go#39761.

Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
@mvdan
Copy link
Member

mvdan commented Jun 25, 2020

Since build.Default is a global variable, wouldn't a call to go env add quite a lot of cost to the init function?

@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 25, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Jun 25, 2020
@heschi
Copy link
Contributor Author

heschi commented Jun 25, 2020

Definitely, 20ms at least. I was assuming that it would directly open and parse the config file.

@mvdan
Copy link
Member

mvdan commented Jun 28, 2020

Gotcha - I assume that is acceptable, given that go/build and cmd/go are released together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants