Based on this comment, I think we should be able to have a target like this:

py_binary(
    name = "foo",
    srcs = ["foo.py"],
    args = [
        "--buildozer",
        "$(rootpath @buildozer)",
    ],
    data = [
        "@buildozer",
    ],
...
)

However, we had to make sure buildozer_binary repo visible to the main repo, otherwise rlocation would fail to resolve. Is this intended or could be improved?

We shell out $(rootpath @buildozer) from the foo.py, if that matters.

It's meant to be usable without any use_repos, but you have to use a runfiles library to find it (you can get the path via $(rlocationpath @buildozer)) and set the env vars for subprocesses, see https://github.com/bazel-contrib/rules_python/tree/main/python/runfiles

Let me know if that doesn't work.

Do you mean we should use Rlocation in Python code instead of rootpath in BUILD.bazel? Or maybe it is env.update(r.EnvVars()) that really matters?

I will give it a try.

OK I see rlocationpath in BUILD.bazel and Rlocation in Python resolve to different paths:

.../execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/tools/foo/foo.runfiles/_main/buildozer+/buildozer
.../execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/external/buildozer+/buildozer

The first path doesn't even exist. rootpath could resolve to the correct path .../execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/tools/foo/foo.runfiles/_main/../buildozer+/buildozer, but subprocessing that fails for finding buildozer.exec.

Using Rlocation together with env update does work.

Rlocation + setting env vars is what is guaranteed to work on all platforms, even if further subprocesses use runfiles. That's what the runfiles library can guarantee (caveat: if processes change the CWD, they need to ensure that runfiles env vars are absolute).

Everything else is "may work, may not work, may break in the future" territory.

That is very good to know. We will refactor this part of our code to go with Rlocation+env. Thank you so much for the help!