bazel_dep should allow specifying a maximum supported compatibility_level

[brentleyjones]

Description of the feature request:

bazel_dep should gain something like a max_compatibility_level which would allow specifying an upper bound for a dependency. The version would imply the lower compatibility_level.

What underlying problem are you trying to solve with this feature?

Image that rules_apple depends on another module, rules_swift, at version=1.0.0/compatibility_level=1. Then rules_swift makes an API breaking change and bumps to version=2.0.0/compatibility_level=2. In subsequent change to rules_apple it accommodates the new API in a way that it can use either version/compatibility_level of rules_swift. Currently there is no way to declare that in bazel_dep, because bazel_dep(name = "rules_swift", version = "1.0.0") will cause a resolution issue if another dep or the root module declares a dependency on rules_swift 2.0.0, and bazel_dep(name = "rules_swift", version = "2.0.0") will do the same the other way. Ideally it could do this instead: bazel_dep(name = "rules_swift", version = "1.0.0", max_compatibility_level = 2) to say that it supports both.

This is a real problem that I see happening very soon, just with different example rulesets (rules_xcodeproj and rules_apple).

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

https://bazelbuild.slack.com/archives/C014RARENH0/p1675176300407969

[brentleyjones]

cc @Wyverald

[brentleyjones]

cc @meteorcloudy

[meteorcloudy]

I actually like this idea after thinking about it ;) It could make bumping compatibility_level of a module less of a problem and reduce the needs to override module version in the root module.

But we need to think through how this would affect our version selection algorithm.

Currently, we group all modules appeared in the dependency graph by module name and compatibility level, then we select the newest version for each group. We fail the resolution if different compatibility levels are required after resolution and pruning unless multiple_version_override is specified.

To allow max_compatibility_level , we can change the process to only group modules by module name, do the MVS resolution, and check if each module still depends on their dependencies at an acceptable compatibility level.

With multiple_version_override, it's a bit more complicated, but I think it'll still work after adding the max_compatibility_level attribute.

Also, I don't think this is going to be an incompatible change. Because what used to work should also work in the new resolution process. Therefore, we can even try to cherry-pick this back to 6.0. /cc @Wyverald WDYT?

[Wyverald]

It's hard for me to predict the impact of such a feature, but I don't have a better idea for now so I won't block it. It's worth noting that using the max_compatibility_level parameter will cause a module to be unusable for any Bazel version <= 6.0. That's technically not a breaking change, but it's still rather disruptive.

[brentleyjones]

Awesome. Thanks.

Does the P2 mean no one on the Bazel team is going to work on it? I would like to get this into 6.1.

[Wyverald]

Unfortunately I don't think we'll have time for it, given 6.1 cut is like ~a week or two away. There are some higher-priority things we need to address. I'm happy to review PRs, though, if anyone wants a go.

[brentleyjones]

I'm working on this. It probably won't make the 6.1 rc cut, and I'll leave it up to your discretion once you start reviewing it if we could get it into 6.1. 6.2 isn't the worst place for it to land though.

[Wyverald]

@bazel-io fork 6.2.0