bazelbuild
differing goroots depending on which MODULE.bazel gosdk call
This is one bazel 8.4.2 and rules_go 0.58.3.
It's unclear where to set GOROOT for vscode that will be consistent across different MODULE.bazel set ups. I'm attempting to update the Editor setup wiki page and noticed the difference between from_file and download
If you use
module(
name = "foobar",
)
bazel_dep(name = "rules_go", version = "0.58.3")
go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")
go_sdk.from_file(go_mod = "//:go.mod")
you'll get an GOROOT at
bazel-${BAZEL_MODULE_NAME}/external/rules_go++go_sdk+main___download_0/
If you use
module(
name = "foobar",
)
bazel_dep(name = "rules_go", version = "0.58.3")
go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")
go_sdk.download(
name = "go_sdk",
version = "1.25.0",
)
you'll get a GOROOT at bazel-${BAZEL_MODULE_NAME}/external/rules_go++go_sdk+go_sdk
It would be nice to consolidate these into one path.
It's also unclear if that main in the first GOROOT path is always the same across repos. The current Editor setup wiki page claims it may be, but I'm not sure what config changes it.
Since the guidance is that canonical repo names should not be hardcoded, stable paths require an additional layer of indirection anyway. I created bazel_env.bzl specifically for this purpose. Its example shows how you can use it to get a stable path to the Go toolchain. The unfortunate part is that this currently requires a recent rolling release of Bazel, but Bazel 9 is around the corner.
Yeah, but that direnv stuff doesn't work for every editor. If bazel is really going the route of having no way to give filesystem guarantees built in, it really feels like we need some kind of equivalent of LSP but for builds here. Tools need to know where Go roots are, and we could get it for them.
bazel_env.bzl doesn't require direnv for its toolchains, just for tools. I should probably clarify that in the docs, but it does simply create a stable path without any external tool requirements.