Description
🐞 bug report
Affected Rule
Dependency on stardoc & protobuf cause this issue.
Is this a regression?
Yes, the previous version in which this bug was not present was: 0.38.0
Description
Due to stardoc 0.7.x and protobuf 29.0 dependency, rules_kotlin is fetched. Even though there are no targets directly depending on rules_kotlin, I think it is fetched probably because rules_kotlin contains a toolchain declaration.
🔬 Minimal Reproduction
Set up the workspace like the following:
==> ./MODULE.bazel <==
module(name = "hah")
bazel_dep(
name = "rules_python",
version = "0.39.0",
)
# local_path_override(
# module_name = "protobuf",
# path = "protobuf",
# )
# local_path_override(
# module_name = "stardoc",
# path = "stardoc",
# )
==> ./BUILD.bazel <==
load("@rules_python//python:py_library.bzl", "py_library")
py_library(
name = "foo",
srcs = [],
)
==> ./stardoc/MODULE.bazel <==
module(name = "stardoc")
==> ./protobuf/MODULE.bazel <==
module(name = "protobuf")
==> ./protobuf/bazel/cc_proto_library.bzl <==
cc_proto_library = None
==> ./protobuf/bazel/BUILD.bazel <==
==> ./protobuf/bazel/java_proto_library.bzl <==
java_proto_library = None
==> ./protobuf/bazel/java_lite_proto_library.bzl <==
java_lite_proto_library = None
A tarball is also attached for quick repo:
workspace.tar.gz
With Bazel 7.4.0 (see explanation below), run the following:
bazel clean --expunge && bazel build //:foo
ls $(bazel info output_base)/external/*rules_kotlin*
We can see that rules_kotlin is fetched.
Now open the root MODULE.bazel file and make the following edits, then re-run the aforementioned commands.
- If rules_python were 0.38.0, rules_kotlin would not be fetched. This is because it relies on older stardoc and protobuf that does not need rules_kotlin.
- If rules_python is 0.39.0, but local_path_override() for stardoc and protobuf were uncommented, then rules_kotlin would not be fetched. This is because rules_kotlin is no longer in the dependency tree.
- If rules_python were modified locally (with local_path_override()) so that it cuts the protobuf dependency and sets the stardoc dependency as
dev_dependency = True
, then rules_kotlin is not fetched.
🌍 Your Environment
Operating System:
Linux
Output of bazel version
:
Build label: 7.4.0
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Tue Oct 22 17:24:25 2024 (1729617865)
Build timestamp: 1729617865
Build timestamp as int: 1729617865
Note: I intentionally pick 7.4.0 not the latest 8.0.0 because its bazel_tools has lower-version dependencies that won't affect our experiment with protobuf, rules_jvm_external and stardoc. With 8.0.0, Bazel mod version resolution always sets higher version for protobuf and rules_jvm_external, so we can't independently verify that the issue does not happen with rules_python@0.38.0.
Rules_python version:
0.39.0
0.40.0
1.0.0
Anything else relevant?
The core issues here is that rules_python depends on Protobuf and Stardoc, two very big repositories with a lot of dependencies, with PITA reasons.
For Protobuf, ideally py_proto_library should come from rules_proto not rules_python. AFAIK this is #2173.
For Stardoc, this appears to come from 5978390. Usually, Stardoc should be a dev_dependency so that the root module can choose whether it wants Stardoc. But rules_python provides sphinx_stardoc
which requires a non-dev dependency on Stardoc. I can file a separate bug to track this if it makes more sense.
Both have heavy dependencies on Java and Kotlin, not to mention the Maven dependencies that Stardoc has. As the code grows, it is highly possible that Stardoc and Protobuf have even more dependencies in the future, where some may contain toolchains, causing users of rules_python to vendor them to have offline builds. I found it very funny that rules_python has Java dependencies.
Context: Android kernel builds are executed by Google's build servers and partner's build servers that cannot reach the Internet. Therefore, all dependencies must be imported into AOSP with careful reviews. Because the Android kernel build does not contain any Java, Protobuf (yet) or Kotlin code, it is hard for us to justify that rules_kotlin should be imported.