Use more Bazel module dependencies #11767
Conversation
|
Looks like |
ejona86
left a comment
ejona86
left a comment
There was a problem hiding this comment.
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.
| bazel_dep(name = "googleapis", repo_name = "com_google_googleapis", version = "0.0.0-20240819-fe8ba054a") | ||
| # CEL Spec may be removed when cncf/xds MODULE is no longer using protobuf 27.x | ||
| bazel_dep(name = "cel-spec", repo_name = "dev_cel", version = "0.15.0") | ||
| bazel_dep(name = "envoy_api", version = "0.0.0-20241214-918efc9") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
How long do you plan to support Protobuf v23 support?
There was a problem hiding this comment.
#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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
With #12243 merged, where does this stand? We should be in a dramatically better place. Do you think you are now able to upgrade all the versions to your preferences in your own project? |
|
Closing, as this is no longer relevant after the deps here were removed in #12243 |
2 participants
This allows bzlmod version resolution and avoids ODR violations when importing the same dependency multiple times in different modules.