-
Notifications
You must be signed in to change notification settings - Fork 117
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
update rules_go #195
update rules_go #195
Conversation
This is to use protobuf v2 library for Go.
cc @EricBurnett |
Could we also use this occasion to migrate to Gazelle’s new way of naming targets? We still declare some go_default_library targets. |
Which way are you supposed to migrate? I currently feel that there is no established way to handle generated *.pb.go for bazel. Also I'd like to focus only to update bazel rules in this PR. |
ping? |
I'm going to approve this with the hope that it doesn't break anyone, but the recognition that there's a high probability that we'll need to roll back. Having pre-generated go bindings in this repository is really a bad idea because it puts us in the impossible position of trying to make everyone happy. I'd strongly suggest moving to generating your own bindings in your own repository. |
Thanks, but we use this via https://github.com/bazelbuild/remote-apis-sdks. So it is better to have *.pb.go eventually there? |
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.
This is to use protobuf v2 library for Go.