Skip to content
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

Merged
merged 1 commit into from
May 11, 2021
Merged

update rules_go #195

merged 1 commit into from
May 11, 2021

Conversation

atetubou
Copy link
Contributor

This is to use protobuf v2 library for Go.

@google-cla google-cla bot added the cla: yes Pull requests whose authors are covered by a CLA with Google. label May 10, 2021
This is to use protobuf v2 library for Go.
@atetubou
Copy link
Contributor Author

cc @EricBurnett

@EdSchouten
Copy link
Collaborator

Could we also use this occasion to migrate to Gazelle’s new way of naming targets? We still declare some go_default_library targets.

@atetubou
Copy link
Contributor Author

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.

@atetubou
Copy link
Contributor Author

ping?
@bergsieker

@bergsieker
Copy link
Collaborator

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.

@bergsieker bergsieker merged commit cc2ca9a into bazelbuild:master May 11, 2021
@atetubou atetubou deleted the rules_go branch May 12, 2021 04:03
@atetubou
Copy link
Contributor Author

Thanks, but we use this via https://github.com/bazelbuild/remote-apis-sdks. So it is better to have *.pb.go eventually there?

bergsieker pushed a commit that referenced this pull request May 20, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Pull requests whose authors are covered by a CLA with Google.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants