diff options
author | Rubens Farias <rubensf@google.com> | 2021-05-20 12:01:08 -0400 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-05-20 12:01:08 -0400 |
commit | 3e385366f152e99adda5ab5e4857b1ab221ba2fe (patch) | |
tree | 57c2a8771ee32fefaedf766d11c245a46db635aa | |
parent | cc2ca9ad14c4c42e231adc8221c245fdc6f2592a (diff) | |
download | bazelbuild-remote-apis-upstream-master.tar.gz |
Tweak go toolchain declaration to appease rules_go. (#196)upstream-master
Currently this repo exposes one function to install its dependencies,
through switched_rules_by_language which invokes remote_apis_go_deps
for golang.
The issues arises from remote_apis_go_deps declaring **and** registering
a go toolchain. We need to register a go toolchain so we can, eg, run
gazelle to clean this repo's BUILD rules. However, this is problematic
for other repos that may import this one but need a different golang version.
On v0.20.1, rules_go used the argument name `go_version` to specify a version.
Recent `rules_go` releases use `version` for specifying a golang version, so
projects importing this one before #195 would luckily not run into issues.
On v0.27.0, the same argument name is used and `rules_go` does not like that
you may try to attempt registering two golang versions as the current toolchain.
This code exploits that `rules_go` does not currently check that you're trying
to install multiple `go_sdk`s with the same name (in this case, the default name
which is coincidentally `go_sdk`). Luckily, the first one declared takes
precendence, allowing projects importing this one to use a different go version.
(I couldn't actually find a bazel doc stating that registering the same
named toolchain twice would ignore the second registering, but I
managed to test this empirically by calling `go_register_toolchains` and
then loading this repo.)
Naturally, I think the best option long term would be to tweak these go
dependencies into two separate functions where one installs the go toolchain
in this repo's workspaces for eg running gazelle, and another that exposes
the necessary package dependencies for projects that import this one - but
for the interest of my own time and bazel being "complicated", I went with
the easier solution for now, which effectivelly reverts functionality to
pre #195. Besides, breaking the go dependencies install would have to change
the `switched_rules_by_language` signature.
-rw-r--r-- | remote_apis_deps.bzl | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/remote_apis_deps.bzl b/remote_apis_deps.bzl index 735616b..a3a2383 100644 --- a/remote_apis_deps.bzl +++ b/remote_apis_deps.bzl @@ -1,7 +1,7 @@ """Load dependencies needed to depend on the RE API repo.""" load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository") -load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies") +load("@io_bazel_rules_go//go:deps.bzl", "go_download_sdk", "go_register_toolchains", "go_rules_dependencies") def _maybe(repo_rule, name, **kwargs): if name not in native.existing_rules(): @@ -10,7 +10,8 @@ def _maybe(repo_rule, name, **kwargs): def remote_apis_go_deps(): """Load dependencies needed to depend on RE API for Go""" go_rules_dependencies() - go_register_toolchains(version = "1.16.4") + go_download_sdk(name = "go_sdk", version = "1.16.4") + go_register_toolchains() gazelle_dependencies() _maybe( go_repository, |