Wrong version update when using variable

[vorburger]

I noticed that while playing with running it for enola-dev/enola#254 (since you have fixed #401; Thank You!), locally via tools/bazel-steward/update.bash script (not as a GitHub Action, yet) from enola-dev/enola#1145, that it changed line 128 in MODULE.bazel of https://github.com/enola-dev/enola/blob/2bf4eacef9ec69d5fd28e34af9d8e1470a1192f4/MODULE.bazel#L19 from:

GRPC_JAVA_VERSION = "1.69.0"

to

GRPC_JAVA_VERSION = "1.70.0"

However this is wrong, as there (currently, right now; today) there is no 1.70.0 on https://registry.bazel.build/modules/grpc-java, yet.

Perhaps Bazel Steward confuses something with the variable? (It's very cool that it's able to change such variables, BTW!)

[lukaszwawrzyk]

This is unfortunate, the update comes from maven rules and maven artifats fro 1.70.0 are released

    "io.grpc:grpc-netty:%s" % GRPC_JAVA_VERSION,
    "io.grpc:grpc-stub:%s" % GRPC_JAVA_VERSION,
    "io.grpc:grpc-inprocess:%s" % GRPC_JAVA_VERSION,

the variable is shared between bzlmod dep and maven deps.

PRs welcome, but I don't think that we will be able to implement something that coordinates such cross kind updates

[vorburger]

Oh, that's what's causing this?

In that case, I guess the "pragmatic" solution here is to just get rid of the variable...

... I'll give that a try, when I have a minute.

[vorburger]

@lukaszwawrzyk with enola-dev/enola#1166 "fixing" (working around) this issue for me, I'm closing this issue here now. (It's technically not fixed, and theoretically still a bug [about mixing up those versions], but as I was able to work around it, thanks to your analysis and tip. I wouldn't be contributing a PR about this.) Now that I understand it better, this seems too much of a "corner case" to warrant spending any more time on "properly" fixing it. If you disagree, feel free to re-open this issue for you, of course.

[lukaszwawrzyk]

It would be an interesting feature to attempt to update together versions that share a variable i.e. intersect sets of possible versions and select based on that a version that is available and expected for all related dependencies. Yet the architecture is not designed with this in mind, each dependency kind is resolved separately. Thus it is challenging to implement.
As for version variable - if updated by robots, it is safer to use version and dependency name together, then the match is more certain. If multiple variables of the same kind share a version, it can be extracted to a variable, then it is also good to group these dependencies in bazel-steward so that 1 PR updates all of them with a nice 1 line diff.
However there is one potential problem with variables and current heuristics os Bazel Steward. If you have 2 variables with coincidentally the same version number but that refer to unrelated dependencies, bumping might not work.