bazelbuild
Advice around git repos that are both go modules and bzlmod modules
How should we think about git repos which provide both bazel and go functionality? For example, I have a dependency on rules_go in my go.mod, as well as (of course) a bzlmod dependency. How can I keep them in sync, especially w.r.t. patches?
Thank you!
Maybe we should add a dedicated go.mod in the go/runfiles Go package.
This has a number of advantages:
- The version of
rules_gocan be different than the version of this Go package used in yourgo.mod. There is no strict dependency between these two versions. - We avoid indirect dependency over all Go internal dependencies of
rules_go(protobuf/x/tools/grpc/protoc-gen-go-grpc).
The whole division between ‘dependencies from a tool used in the build’ vs ‘dependencies from a library we expect client to link’ is fraught with complexity and danger. C.f. the maven repository name difficulties.
Adding a dedicated go.mod to the runfiles library would be possible.
I'm not sure whether it would greatly improve the situation though since proto and x/tools deps would still need be present. The proto rules link in runtime code, so the version legitimately needs to align with "target configured" deps. x/tools needs to align with "exec configured" targets since users can supply their own nogo analyzers, but I still haven't found a good way to specify different dep versions for target vs. exec configured target. This could also very well lead to more pain than gain.
Fair. So I guess I’m back to the question of how I should think about them being in sync - it feels like skew between the bazel rules and the go code is a recipe for latent bugs, right?
Not really as go_deps will still pick the maximum version. It's only a problem for IDEs that aren't fully Bazel aware.