repository_ctx.path should be able to handle an alias to an exported source file

[Globegitter]

Description of the problem / feature request:

If I try to call repository_ctx.path on a label that corresponds to an alias that points to an exported source file I get the error Not a regular file: .... I would expect that to just give me the path of the actual source file.

Feature requests: what underlying problem are you trying to solve with this feature?

In https://github.com/bazelbuild/rules_nodejs we expose an external repository called nodejs which downloads the node binary for the corresponding host platform to be able to run things like the package manager, etc on the host platform. To make it easy for other call-sites from within the rules itself but also for users we expose an alias node_bin which points to the actual binary, which on linux and darwin is node and on windows 'node.exe'. So now I have to decide on which binary to use in multiple places rather than just relying on that already existing alias.

See code here: https://github.com/bazelbuild/rules_nodejs/pull/827/files#diff-67b0f7c2b38c3bbb6dd40c85eb923174R452

What operating system are you running Bazel on?

Elementary OS 5 (Ubuntu 18.04)

What's the output of bazel info release?

release 0.27.0

Have you found anything relevant by searching the web?

Somewhat related: #3901
Also somewhat related to this specific issue: #1485

[Globegitter]

What makes this even less ideal is that if we want to make it configurable by the user, so they could set themselves what node to run in the repository rules there is no nice way to let them set that with just one label.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[mutongx]

Hi @sgowroji,

I have encountered the same issue when trying to let pybind11_bazel recognize the toolchain create by rules_python. My MODULE.bazel is written as follows:

bazel_dep(name = "rules_python", version = "0.26.0")
python = use_extension("@rules_python//python/extensions:python.bzl", "python")
python.toolchain(
    configure_coverage_tool = True,
    python_version = "3.8",
)
use_repo(python, "python_versions", "python_3_8")

bazel_dep(name = "pybind11_bazel", version = "2.11.1")
python_configure = use_extension("@pybind11_bazel//:python_configure.bzl", "extension")
python_configure.toolchain(python_interpreter_target = "@python_3_8//:python3")
use_repo(python_configure, "local_config_python", "pybind11")

The implementation of python_configure uses repository_ctx.path to find out the actual path of python_interpreter_target. However, @python_3_8//:python3 is an alias pointing to the platform-specific Python interpreter, and so it fails with Error in path: Not a regular file: .../external/rules_python~0.26.0~python~python_3_8/python3.

mutongx/bzlmod-pybind11-fail is a full example that demonstrates the use case. The error can be reproduced by running bazel build //... from this repository. I am using Bazel 7.0.0-pre.20231018.3.

My current workaround is replacing @python_3_8//:python3 with @@rules_python~0.26.0~python~python_3_8_x86_64-unknown-linux-gnu//:bin/python3. Sadly, the label relies on canonical repository name and platform name.

[Wyverald]

Repo rules can only operate on file targets, instead of rule targets like alias. This is because rule targets like alias are only handled during analysis, which happens at a later stage than repo rules. For you specific use case, please take it to rules_python.

[mutongx]

OK. Thanks for your reply!

[junyer]

@pythons_hub//:interpreters.bzl provides INTERPRETER_LABELS and DEFAULT_PYTHON_VERSION and should resemble this:

INTERPRETER_LABELS = {
    "python_3_11": Label("@python_3_11_x86_64-unknown-linux-gnu//:bin/python3"),

}
DEFAULT_PYTHON_VERSION = "3.11"

@mutongx wants to use a specific Python version whereas I want to use the default Python version, but either way, it should be straightforward to make pybind11_bazel's python_configure.bzl do the needful – as a stepping stone to proper support for rules_python someday.

Ping, @rickeylev and @rwgk. :)