Get the name of current repository from macro

[or-shachar]

Description of the problem / feature request:

I am trying to get the name of the current repository from a macro.

.
├── a
│   ├── BUILD.bazel
│   ├── WORKSPACE
│   ├── empty.txt
│   └── txt_files.bzl
└── b
    ├── BUILD.bazel
    ├── WORKSPACE
    └── empty2.txt

(see full example here )

I want that if repo b will call the macro in @a//:txt_files.bzl then somehow I'd be able to retrieve that it was called from repo b.

Right now (not sure if it's a bug or work as intended) - calling native.repository_name() will return @ and not the name of repo as declared in its WORKSPACE file.

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

I want to change the behavior of a macro based on the callee repository.

Can we allow native.repository_name() to return the explicit name of the repository and not @? To maintain backward compatibility - I assume it would be better if we add a flag to this method that will be turned off by default.

[or-shachar]

As a workaround I wrote the following repository rule:

def _define_repository_name_impl(repository_ctx):
    repository_ctx.file("BUILD.bazel",
        """package(default_visibility = ["//visibility:public"])
        """)
    repository_ctx.file("defs.bzl",
        """main_repository_name="{}"
        """.format(repository_ctx.attr.repo_name))

_define_repository_name = repository_rule(
    implementation = _define_repository_name_impl,
    attrs={"repo_name": attr.string(mandatory=True)}
  )

def define_repository_name(repo_name):
    _define_repository_name(name = "main_repository_name",repo_name = repo_name)

which allows me to load the main repository name by calling:

load("@main_repository_name//:defs.bzl","main_repository_name")

The WORKSPACE file looks like this:

repository_name = "xxx"
workspace(name = repository_name)

load("@bazel_tooling//rules:define_repository_name.bzl","define_repository_name")
define_repository_name(repository_name)

I don't like it... given that workspace() call should be the first line of the WORKSPACE file. But it works (bazel 2.1.0)

[or-shachar]

hey @laurentlb ... May I ask for your opinion on this matter? :-)

[jheaff1]

@or-shachar I have the same issue, did you ever find a resolution to this?

[fmeum]

@or-shachar @jheaff1 Could you describe in more detail what you want to use the name declared in the WORKSPACE file for in a macro? Knowing more about the actual problem you are trying to solve would help me answer these questions.

[Wyverald]

You most likely want just "@" instead. With the recent fixes on repo mapping, "@workspace_name//:foo" is equivalent to "@//:foo".

(Unless you're doing exec path or runfiles shenanigans, in which case refer to @fmeum's comment.)

[jheaff1]

@fmeum I am trying to write a sh_binary target for the rules_foreign_cc repo that wraps around an executable binary (built by rules_foreign_cc) with shared library dependencies. This would allow such a binary to be used as a build tool, eg the protobuf compiler or various generators part of the Qt framework.

I would like to use the rlocation bash function provided here:

bazel/tools/bash/runfiles/runfiles.bash

Line 68 in a76cf2f

# cat "$(rlocation my_workspace/path/to/my/data.txt)"

The rlocation bash function requires the workspace name, which I would like to obtain programatically in a macro.

I’ve tried to use native.repository_name() but that returns @ rather than the name of the repository.

[fmeum]

@jheaff1 Would an analogue of $(location //foo) that returns the correct path for rlocation help you realize this? I could see that being more user-friendly than yet another "some type of name of a repo" thing.

[jheaff1]

@fmeum Absolutely that would be very useful. Ive found that using $(rootpath rather than $(location provides exactly what $(rlocation requires apart from the workspace name.

[fmeum]

@lberki I have been thinking about proposing a $(location ...) variant that returns the correct path for Rlocation for a while. The way runfiles work with Bzlmod would almost make this a requirement for location expansion to remain useful in args. What do you think?

[lberki]

@fmeum without taking sides on the `$(location) question, it's a feature orthogonal to the one proposed in this bug.

re: this bug in particular, what is the argument against introducing repository_name()? Naively, one would think that it's a very logical extension to package_name(). @Wyverald maybe you can think of a counter-argument?

[Wyverald]

this bug in particular, what is the argument against introducing repository_name()? Naively, one would think that it's a very logical extension to package_name(). @Wyverald maybe you can think of a counter-argument?

We already have native.repository_name and it does what it says on the tin (https://bazel.build/rules/lib/native#repository_name). @fmeum's & @jheaff1's question is more about the runfiles/execpath use case, where we sometimes need the workspace name, which is only accessible right now in a rule ctx object (https://bazel.build/rules/lib/ctx#workspace_name; also to note, not the same as Label.workspace_name...)

[lberki]

@Wyverald I'm embarrassed! I specifically looked for the identifier called repository_name and didn't find it in the source code. My bad.

[lberki]

The issue with making the (global) workspace name available in Starlark code is that then the evaluation of BUILD files in external repositories would be a function of the content of the main repository, which isn't too intuitive (it's problematic enough for ctx.workspace_name(), but we can't help that because that's how runfiles work at the moment.

[fmeum]

@lberki That plus the fact that having yet another workspace_name would be confusing made me think that being able to get Rlocation paths out of location expansion may indeed be the best solution to this issue (see also the comment by @jheaff1). Since native.repository_name returns the right identifier for everything except runfiles discovery, why not add a way for users to get the full runfiles path right away without having them stitch it together themselves?

[lberki]

The reason why I was confused is that for some reason, I thought $(rlocation) is already a thing in Bazel so I went on a wild goose chase trying to figure out what else you want :)

I think both adding $(rlocation) and the same method to File is reasonable. @Wyverald , it looks like you also agree?