Can cel-spec be a dev dependency

[honnix]

Maybe stupid question. Can cel-spec added here https://github.com/grpc/grpc-java/pull/11417/files#diff-6136fc12446089c3db7360e923203dd114b6a1466252e71667c6791c20fe6bdcR51 be a dev dependency, so it doesn't get propagated. It's an old version which makes gazelle unhappy when a project has a later version of cel-spec as a go module: https://github.com/bazel-contrib/bazel-gazelle/blob/a8e48fd344cee0adbff2cc846da972c6d941e397/internal/bzlmod/go_deps.bzl#L612

[kannanjgithub]

You need to add dependency on cel-spec to upgrade it to the version expected by gazelle.

Gazelle is complaining because the versions don't match so you need to make them match. This solely involves your own dependency tree.

[kannanjgithub]

I hope your concern is resolved. Feel free to comment to reopen the issue in the future if needed.

[honnix]

I'm not sure it is. My question is whether it is necessary for cel-spec to be a non-dev bazel dependency in grpc-java. I understand how to resolve the inconsistency.

[kannanjgithub]

We are using http_archive tool to add the cel-spec dependency and this tool doesn't provide a way of declaring a dependency as a dev dependency.

[honnix]

We are using http_archive tool to add the cel-spec dependency and this tool doesn't provide a way of declaring a dependency as a dev dependency.

It is defined here

grpc-java/MODULE.bazel

Line 54 in bb120a8

bazel_dep(name = "cel-spec", repo_name = "dev_cel", version = "0.15.0")

, so that should be possible to do. Or maybe I'm looking at the wrong place.

[kannanjgithub]

Thanks for pointing that out, I was going off of the repositories.bzl link in the first post.

[kannanjgithub]

Cel-spec cannot be a dev dependency, it is a real dependency used in the generated code for envoy protos in Xds.

[honnix]

Thank you for explaining. Can it be left to users to pull in via go.mod and gazelle? The bundled version is pretty old now.

[kannanjgithub]

Our users do not use gazelle. But we need it for both the protos and the non-generated code it has.

You should depend on the newer version of the dep in your own repo. If that doesn't work, then you should file a bug against gazelle, because "that is how bzlmod works".

There's no way we can avoid depending on all dependencies that also have go code.

[honnix]

Our users do not use gazelle. But we need it for both the protos and the non-generated code it has.

You should depend on the newer version of the dep in your own repo. If that doesn't work, then you should file a bug against gazelle, because "that is how bzlmod works".

There's no way we can avoid depending on all dependencies that also have go code.

Thank you for explaining. I think I understand it better now after working on #11980.