aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRubens Farias <rubensf@google.com>2021-05-20 12:01:08 -0400
committerGitHub <noreply@github.com>2021-05-20 12:01:08 -0400
commit3e385366f152e99adda5ab5e4857b1ab221ba2fe (patch)
tree57c2a8771ee32fefaedf766d11c245a46db635aa
parentcc2ca9ad14c4c42e231adc8221c245fdc6f2592a (diff)
downloadbazelbuild-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.bzl5
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,