Starlark file @@bazel_tools//tools/build_defs/repo:cache.bzl is not visible for loading from package `@@rules_doxygen~//` ...

[filmil]

When using the module version 2.2.1 with a fairly vanilla MODULe.bazel import:

╰─>$ clear && bazel build //:docs
ERROR: /home/filmil/.cache/bazel/_bazel_filmil/fba57cb1498e5edac648620d88e186c0/external/rules_doxygen~/extensions.bzl:3:6: Starlark file @@bazel_tools//tools/build_defs/repo:cache.bzl is not visible for loading from package @@rules_doxygen~//. Check the file's `visibility()` declaration.
ERROR: Error loading '@@rules_doxygen~//:extensions.bzl' for module extensions, requested by <REDACTED>:38:34: module @@rules_doxygen~//:extensions.bzl contains .bzl load visibility violations: module @@rules_doxygen~//:extensions.bzl contains .bzl load visibility violations
INFO: Elapsed time: 5.220s
INFO: 0 processes.
ERROR: Build did NOT complete successfully

[filmil]

The complaint looks legit: https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/repo/BUILD#L23 is indeed private.

[filmil]

Bazel version:

╰─>$ bazel version
Bazelisk version: v1.13.2
Build label: 7.3.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Aug 19 16:12:50 2024 (1724083970)
Build timestamp: 1724083970
Build timestamp as int: 1724083970

[TendTo]

Hi, thank you for the precise report.

I was able to effortlessly reproduce the bug by adding a .bazelversion file in order to use bazel version 7.3.1.
I'm not a bazel guru, but I don't think the like you linked is the cause of the problem, as it simply states I cannot depend on the target mock_srcs, (i.e., the filegroup), which I'm not using anyway. Instead, I'm pretty sure the problem arises from this line, which was later changed in commit 6052ad65e4185f19944e5138e9b70f6a4eaf9e76.

While not ideal, I guess the only solution to support bazel versions older than that commit is to include the implementation in rules_doxygen, so that we don't depend on anything else. I'll soon submit a pr.

Let me know if you have any other suggestions or know some better ways.

[filmil]

Thank you for fixing this. I didn't spot the change to this line

Let me know if you have any other suggestions or know some better ways.

Since the code in cache.bzl isn't all that complicated, I agree that copying it over is a reasonable fix.

[filmil]

Another question - would it be possible to run the presubmit checks also with bazel 7.x to ensure compatibility?

Or, if that isn't possible, perhaps have compatibility table somewhere?

[TendTo]

The funny thing is that the presubmit already checks for Bazel 7.x. In other words, the change must have happened in a minor version change.
This said, I have added some additional checks in the github CI that explicitally target Bazel 7.0.0 and 8.0.0, which are the two versions I was planning to support, along with future ones, since they made Bazel modules support official starting from Bazel 7. I hope that this will allow me to spot these kind of oversights easily in the future.

[TendTo]

In any case, if everything works now, I will simply upload the fix in the new version of rules_doxygen later today.

[filmil]

I think any sort of guidance that helps a user select the correct version of rules_doxygen for their situation would work.

That said, with the fix applied, rules_doxygen run beautifully. Thanks!