Feature request: allow labels as path argument of local_repository rule

[smolkaj]

Description of feature request:

The path argument of the local_repository rule can currently be only a relative or absolute path, see https://docs.bazel.build/versions/master/be/workspace.html#local_repository_args.
This request asks to support labels as well.

What underlying problem are you trying to solve with this feature?

Projects using the local_repository rule are currently not compositional in the sense that they brake when nested inside other Bazel projects. The root cause is that relative paths are resolved with respect to the including project instead of the included project.

Details

To allow the nested use of bazel projects within other bazel projects, it is customary to define a function <project name>_deps that sets up all necessary repositories like so:

# awesome_project/awesome_project_deps.bzl
def awesome_project_deps():
    """Loads dependencies need to compile this project."""
    if not native.existing_rule("com_google_googletest"):
        http_archive(
            name = "com_google_googletest",
            urls = ["https://github.com/google/googletest/archive/release-1.10.0.tar.gz"],
            strip_prefix = "googletest-release-1.10.0",
            sha256 = "9dc9157a9a1551ec7a7e43daea9a694a0bb5fb8bec81235d8a1e6ef64c716dcb",
        )
        native.local_repository(
            name = "com_google_protobuf",
            // If we call this function from another Bazel project, the below path will be
            // interpreted relative to the root of that project, causing breakage. 
            path = "third_party/protobuf",
            // This problem could be solved by allowing the use of labels:
            // path = "@com_github_awesome_project//:third_party/protobuf",
        )
    ...

Users of the project can then load all transitive dependencies by calling the function in their WORKSPACE file:

# another_project/WORKSPACE
load(@com_github_awesome_project//:awesome_project_deps.bzl, awesome_project_deps)
awesome_project_deps()  # Fails because `another_project/third_party/protobuf` does not exist.

Here are examples of this pattern in widely used projects: protobuf, grpc, ...

Unfortunately, this pattern brakes when local_repository together with a local path is used by the project one includes, as the relative path is resolved with respect to the root of the including (rather than the included) project.
The problem could be solved by using a label instead of a relative path, since labels can be absolute rather than relative.

[smolkaj]

@stefanheule FYI

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[sudoforge]

@bazelbuild/triage please review this issue; i believe it is a valid feature request.