Use more Bazel module dependencies

[mering]

This allows bzlmod version resolution and avoids ODR violations when importing the same dependency multiple times in different modules.

[mering]

Looks like Label().repo_name was only introduced in Bazel 7.1. Can we bump the version?

[ejona86]

We can upgrade the CI to Bazel 7.1, but the failure looks to be because of envoy_api and we can't use that dependency anyway.

[ejona86]

We can't upgrade protobuf beyond 23.1 for a good while yet because of the new protobuf-java major version (we support the newer version, but we need to support the older version too). So we can't use this dependency.

The same problem impacts the xds dependency.

[mering]

Then you won't be able to support Bazel 8+ which moved java rules to rules_java which in turn uses a newer Protobuf version and java proto rules to Protobuf itself which is also only available since a recent version.

[ejona86]

I've already tried compiling with Bazel 8 and didn't see any problem. If rules_java requires the newer Protobuf, then yeah, we can't use it.

[mering]

How long do you plan to support Protobuf v23 support?

[ejona86]

#11015 (comment) describes the current status but it's essentially, "as long as needed." Practically, Protobuf Java 5.x is on hold until we and some other libraries can upgrade to 4.x. If we're lucky, maybe we upgrade middle of 2025?

I see Bazel 8.0.0 is bringing in protobuf@29.0, simply because I see protobuf@23.1 when using Bazel 7.0.0. mod graph and mod explain seem useless for investigating what module brings in which version. I'm not impressed... The versions are just wrong/unhelpful in the output. It's nice to know protobuf@29.0 is the selected version, but what versions were actually requested by the dependencies?

$ USE_BAZEL_VERSION=8.0.0 bazelisk mod explain protobuf
<root> (grpc-java@1.70.0-SNAPSHOT)
...
├───protobuf@29.0 
...

$ USE_BAZEL_VERSION=8.0.0 bazelisk mod graph
<root> (grpc-java@1.70.0-SNAPSHOT)
...
├───cel-spec@0.15.0 
│   ├───bazel_skylib@1.7.1 (*) 
│   ├───protobuf@29.0 (*) 
...
├───protobuf@29.0 
...

It seems users are not able to upgrade to Bazel 8, rules_java 8.x, rules_proto 7.x, and even things like rules_cc 0.0.15, until their dependencies are protobuf-4.x compatible.

[mering]

The ecosystem is evolving quickly. Would it be an option that people who want to use an old version of protobuf having to use an old version of other dependencies like grpc-java as well? Then grpc-java on head can move on to newer versions of dependencies.

[ejona86]

Not really, because then we'd need to support the older version of gRPC longer and it'd impact downstreams as well. It also makes upgrading harder because you have to upgrade many things as once. Because protobuf is releasing incompatible versions doesn't mean grpc-java should take on the extra burden.

We do push Bazel faster than we do other things, because it is changing so much. But the protobuf compatibility issues have been a giant mess without adding the Bazel issues on top.