How to Use Unreleased Features in Bazel Rule Sets with git_override

Sometimes, you’ll encounter a feature in a rule set that’s already been completed, but the new release isn’t available yet. It’s frustrating to see that shiny feature sitting unused in the repo, just out of reach. Thankfully, with git_override, you can check out any commit hash you want and start using it without waiting for a new release.

I recently faced this issue while wanting to use the unreleased pyi file generation feature in the rules_proto_grpc_python rule set.

In this post I'll explain how to override Bazel modules in a slightly complex rule set repo, using this example.

To use a specific commit hash for this rule set, you can add the following to your MODULE.bazel file:

bazel_dep(name = "rules_proto_grpc", version = "5.0.1")

git_override(
    module_name = "rules_proto_grpc",
    remote = "https://github.com/rules-proto-grpc/rules_proto_grpc.git",
    commit = "d17b5b16c8b12143c6f1b78dabd6bbc228e89b58",
    strip_prefix = "modules/core",
)

bazel_dep(name = "rules_proto_grpc_python", version = "5.0.1")

git_override(
    module_name = "rules_proto_grpc_python",
    remote = "https://github.com/rules-proto-grpc/rules_proto_grpc.git",
    commit = "d17b5b16c8b12143c6f1b78dabd6bbc228e89b58",
    strip_prefix = "modules/python",
)

There are two main complications with this rule set:

1. Multiple rule set modules exist under the modules/ directory of the repo.
2. rules_proto_grpc_python depends on rules_proto_grpc, which lives in the same repo.

1. Multiple Modules in the repo

The first complication arises from the multiple modules under the modules/ directory. When using git_override, Bazel needs to know where to find the appropriate MODULE.bazel for the override. If the module names don’t match, it will throw an error. That means that if you don’t use the strip_prefix attribute, Bazel will try to use the root MODULE.bazel (which doesn’t have the same name), and you’ll encounter an error like this:

ERROR: Error computing the main repository mapping: in module dependency chain <root> -> rules_proto_grpc_python@_: the MODULE.bazel file of rules_proto_grpc_python@_ declares a different name ()

The solution is to use the strip_prefix parameter to define the root of the module. This works because, under the hood, Bazel is using the git_repository rule. A bit cryptic, but it’s how Bazel rolls :).

2. The in-repo dependency

The second complication is that rules_proto_grpc_python depends on rules_proto_grpc, that lives in the same repo. They also both are released toghether and use the same version. Even though you don’t need to add this dependency when not using git_override, you must do so in this case. If you omit it, Bazel will throw an error like this:

ERROR: Error computing the main repository mapping: module not found in registries: [e-mail]

This happens because the MODULE.bazel for the Python ruleset contains a reference like this:

bazel_dep(name = "rules_proto_grpc", version = "0.0.0.rpg.version.placeholder")

The override registers rules_proto_grpc with the placeholder version, allowing the dependency to resolve correctly.