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

[aiuto]

What happened?

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

• Add rules_pkg 1.0.1 (was 1.0.0) #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]

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]

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

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

[aiuto]

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]

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.

[Wyverald]

Closing as this doesn't seem actionable -- we can reopen if you have other suggestions.

[aiuto]

This is actionable. We could change the repository update to be able to ignore bzlmod loops that don't matter.

…

On Tue, Jul 23, 2024 at 6:37 PM Xùdōng Yáng ***@***.***> wrote: Closing as this doesn't seem actionable -- we can reopen if you have other suggestions. — Reply to this email directly, view it on GitHub <#2232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHFN7OM4ECYPBETDL6TZN3LJZAVCNFSM6AAAAABJE4OUPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWGQZDGMZUHA> . You are receiving this because you authored the thread.Message ID: <bazelbuild/bazel-central-registry/issues/2232/2246423348 ***@***.***>