[Bug]: It is impossible to bump compatibility level if you mutually depend on another module.

aiuto commented 4 weeks ago

What happened?

Trying to add rules_pkg/1.0.0, which bumps compatibility_level. Presubmit fails:

https://github.com/bazelbuild/bazel-central-registry/pull/2180
https://buildkite.com/bazel/bcr-presubmit/builds/6179#0190084e-eb88-447c-9f83-9c84070c8fca
Protobuf depends on us at capability level 1.
Since this is a breaking change, we are at level 2.
We depend transitively on protobuf but don't use it.

So, the obvious problem with enforcing this

If I bump protobuf to depend on the new version, that will fail because this is not submitted yet.
If I include protobuf in rules_pkg/MODULE.bazel, I suspect that won't help, because we'll still be at mismatched levels.

Version

module(
    name = "rules_pkg",
    version = "1.0.0",  # Must sync with version.bzl.
    compatibility_level = 2,
    repo_name = "rules_pkg",
)

# Do not update to newer versions until you need a specific new feature.
bazel_dep(name = "rules_license", version = "0.0.7")
bazel_dep(name = "rules_python", version = "0.31.0")
bazel_dep(name = "bazel_skylib", version = "1.4.2")

# Only for development
bazel_dep(name = "platforms", version = "0.0.9", dev_dependency = True)
bazel_dep(name = "rules_cc", version = "0.0.9", dev_dependency = True)
bazel_dep(name = "stardoc", version = "0.6.2", dev_dependency = True)

# Find the system rpmbuild if one is available.
find_rpm = use_extension("//toolchains/rpm:rpmbuild_configure.bzl", "find_system_rpmbuild_bzlmod", dev_dependency = True)
use_repo(find_rpm, "rules_pkg_rpmbuild")

register_toolchains(
    "@rules_pkg_rpmbuild//:all",
    dev_dependency = True,
)

How to reproduce

https://github.com/bazelbuild/bazel-central-registry/pull/2180

Any other information?

No response

aiuto commented 4 weeks ago

Possible solution:

Allow bazel_dep(min_version="...", [max_version="..."])
This would just make sure we get any version of the package at least min_version.
and no more than max_version

rules_proto only cares about the most backwards portable pieces of rules_pkg, so it would set min_version="0.1.0". Then it could pick up either the 0.x series or the 1.x series.

Another solution: Loops in module dependencies that come back to different compatibility levels are allowed, with a warning message.

Or that the compatibilty_level of anything specified in the project MODULE.bazel wins in favor of any explicit versions called out transitively. Maybe that happens in general, but not if the compat level is in the module() stanza.

Wyverald commented 4 weeks ago

Allow bazel_dep(min_version="...", [max_version="..."])

We already have this: https://bazel.build/rules/lib/globals/module#bazel_dep.max_compatibility_level

aiuto commented 4 weeks ago

OK. That is half the battle. But the problem remains that I have to modify rules_proto to push my new version of rules_pkg. That is a lot of friction.

Wyverald commented 4 weeks ago

Well, yes... I don't know what your expected outcome is. If you upload a version of rules_pkg which transitively depend on some rules_proto, you need to at least depend on a rules_proto that can work with the rules_pkg you're uploading. That seems reasonable to me.

At the end of the day, incrementing the compatibility level of your module is a big deal. Bazel's default here is to be safe and disallow multiple compatibility levels to coexist -- the other alternatives are bad in their own ways.

bazelbuild / bazel-central-registry