@buildozer//:buildozer should have public visibility

[vonschultz]

I'm using Bazel 7.0.0 and bazel_dep(name = "buildozer", version = "6.4.0").

I'm getting the error

target '@@buildozer~6.4.0//:buildozer' is not visible from target '//tools/common/bazel:make_buildozer_wrapper'.

I would expect @buildozer a.k.a. @buildozer//:buildozer to have public visibility, so that I can make a wrapper that depends on it. It is supposed to be part of the public API of the module, isn't it?

[fmeum]

It's not currently built in a way that would properly support this use case, which is why the target hasn't been marked public yet.

What would you like to do with the target? I can look into adding support for your use case.

[vonschultz]

I'm doing

load("@aspect_bazel_lib//lib:expand_template.bzl", "expand_template")
expand_template(
    name = "make_buildozer_wrapper",
    out = "buildozer_wrapper.py",
    data = ["@buildozer"],
    substitutions = {
        "$(location @buildozer//:buildozer)": (
            "$(location @buildozer//:buildozer)"
        ),
    },
    template = "buildozer_wrapper.tpl.py",
)

The wrapper does some set up, calls buildozer with subprocess.run() and the path from the location substitution, and then tidies up.

The wrapper use case is generic, in that different people may want to do different things. My specific use case is to first rename all the BUILD.bazel files to BUILD as buildozer doesn't (didn't?) support BUILD.bazel files, and then rename them back again after buildozer ran, as well as mapping return codes 0 and 3 from buildozer (success with changes, and success without changes) to return code 0 from the wrapper. (The wrapper is called by a shell script that does the desired changes, and the shell considers exit code 3 a failure.)

[fmeum]

Could you try replacing @buildozer//:buildozer with the contents of load("@buildozer//:buildozer.bzl", "BUILDOZER_LABEL")? That directly gives you the binary, not the wrapper target, which avoids the setup issues and is publicly visible. If that works, I can update https://github.com/fmeum/buildozer?tab=readme-ov-file#using-buildozer-in-repository-rules-and-module-extensions to mention this case.

[vonschultz]

Yes, that works. Thank you!

(Full disclosure: I had to change $(location [...]) to $(rlocationpath [...]) and use bazel_tools.tools.python.runfiles in my wrapper to find the file, but that may be because I'm upgrading to Bazel 7 and is probably unrelated to Buildozer itself.)

[fmeum]

I would recommend using @rules_python//python/runfiles instead as it's compatible with Bzlmod and maintained.