bazelbuild
MODULE.bazel has incorrect version
🐞 bug report
Affected Rule
The issue is caused by the file:https://github.com/bazelbuild/rules_python/blob/2b5447bca3b85141aedc7676f83a19ea2f030739/MODULE.bazel#L3
Is this a regression?
Yes, the previous version in which this bug was not present was: ....No
Description
MODULE.bazel declares version 0.0.0, but it should be 0.27.1 (or the version of the release)🔬 Minimal Reproduction
N/A
🔥 Exception or Error
N/A
🌍 Your Environment
Operating System:
N/A
Output of bazel version:
N/A
Rules_python version:
0.27.1
Anything else relevant?
The Kleaf team (Build Android kernels with Bazel) is migrating to bzlmod. We check out rules_python in Gerrit (link). When migrating to bzlmod, in order to avoid fetching from registry.bazel.build directly, we are creating a local registry. To create a local registry, we need an automated way to figure out the module version for the project checked out on Gerrit.
For other projects like rules_java, rules_cc etc., we can just read from MODULE.bazel directly. But for rules_python, MODULE.bazel always contains 0.0.0.
On the registry, the version is set properly, e.g.
https://github.com/bazelbuild/bazel-central-registry/blob/a26099e5ffa366811cb82240881f5bdb7648d1ca/modules/rules_python/0.27.1/MODULE.bazel#L3
Can MODULE.bazel be populated with the correct version?
Thank you!
In the BCR there is a patch that bumps the version to the correct version. Since we use automation to make releases, maintaining the version number manually would be something that would create overhead in making releases.
Let me know if that is sufficient for your needs.
If we could somehow ensure the version is kept up to date, I'd be +1 on this. I've wanted something similar for the doc gen and to allow users to version detect on the rules_python version directly. (The docs saying "version latest" I find uninformative, "version 0.27.0+3" is more informative IMHO)
In this case, though, the issue i see is the version in git is only accurate for the particular commit the release is tagged at. For example:
We set version=0.22.0. Then we create a tag at that same commit. Another commit is made. The 0.22.0 version is no longer accurate; it should be 0.23.0 or 0.22.1, depending on what the subsequent commit did. This means every commit has to increment the version, but only the appropriate sub-part, and only if a previous commit didn't do so already. That seems like a lot of manual work, or a fairly complicated presubmit check.
If you're relying on the module version value to indicate the true version, this would be problematic. If you're ok with it acting as a "baseline version", then it'll work ok.
To create a local registry, we need an automated way to figure out the module version for the project checked out on Gerrit.
What I would suggest is synthesizing a version based on the commit difference from the most recent tagged release. e.g., 0.22.0+c5 (or something like that, I forget the semver syntax for expression cherry picks or equiv). I think git describe can do this for you: git describe HEAD will print the latest tag, the number of of commits past, and a hash, e.g. 0.27.0-15-g8896275.
I am thinking that there is nothing we can do here and we should close the issue?