Is there a way to specify env vars for the go toolchain? about rules_go HOT 6 OPEN

but I was hoping to make it work in more bazel-native way...
With standard go toolchain, and go.env file, it is easy to set all the env vars in one place.

I found these two requirements contradicting. Bazel doesn't use the go command from Go toolchain to compile and link. So even with what @fmeum did in #3879, the envs only affects the go command, not the compilation and linking.

In fact, I am worried that go_sdk.config(go_env = {...}) gives users a false impression that they can control compilation and linking by setting things likeCGO_CFLAGS or GOOS there.

So I think the "bazel-native way" is to set the envs in different ways than Go:

• GOPROXY can potentially be set with gazelle_dependencies(go_env = ...) like @fmeum in #3879, but we found it working well to set it in Bazel wrapper (e.g. tools/bazel)
• GOOS is set with --platforms
• CXX, CC should be the C toolchain resolved by Bazel
• GOFLAGS should be set from --@io_bazel_rules_go//go/config:gc_goopts
• This goes on and on...

What I am trying to say is Bazel and Go are two fundamentally different build systems. The behavior of Go build is controlled by env vars, but Bazel prefers configuration files and command line flags.

from rules_go.

Another thought after looking at golang/go@7aa85e0

Should go_register_toolchains just allow to specify go.env file?
https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst#go-register-toolchains
Maybe #3401 should be further generalized to all go env vars?

from rules_go.

Should go_register_toolchains just allow to specify go.env file?

This was actually my first thought as well, but I now see undesirable side effects: The env variables one typically wants to set affect the fetches of dependencies, but not the compilation of .go code itself. If we add these variables to the go.env of the Go SDK, they will be an input to compilation actions and thus affect cache hits.

Instead, we can forward the variables to only the two places related to dependency fetching: @rules_go//go and go_repository.

from rules_go.

@fmeum:
https://pkg.go.dev/cmd/go#hdr-Environment_variables
lists all possible variables, and it seems like is not just about fetches of dependencies.
With standard go toolchain, and go.env file, it is easy to set all the env vars in one place.

But with Bazel some of them can be set by these settings:
https://github.com/bazelbuild/rules_go/blob/master/go/modes.rst#build-settings

Some are chosen for you by rules_go for you:
https://github.com/bazelbuild/rules_go/blame/55ea579a70958d66f24a907433978b21edd36b29/go/private/sdk.bzl#L491

So maybe allowing to specify all env vars in a single place will ease the mental load of users?

from rules_go.

@linzhp makes a very good point. I will change the name of the go_env attribute to something like go_fetch_env to make it clear that build-related env vars won't be read.

from rules_go.

I submitted bazelbuild/bazel-gazelle#1748 instead, which moves the new go_env field to go_deps, hopefully making it more clear that this is only targetted at fetching of Go deps. What do you think?

from rules_go.