native.repository_name() and ctx.workspace_name() are similar function but with different name

[damienmg]

To get the workspace name of the call site, we do native.repository_name() in a macro and ctx.workspace_name() in a rule. The latter is behaving differently in the main repository probably (returning the name, whereas the repository name can be empty).

This is a confusing API and it needs to be cleaned.

[haberman]

I am also finding it confusing that native.repository_name() returns @ for the main repository. Files in runfiles are scoped to the workspace name, but there doesn't appear to be any way to get this workspace name from a macro. So how can I refer to a runfile without copy/pasting the name of the workspace from WORKSPACE?

[mpictor]

I'd also find it very useful to be able to get the "real" workspace name inside a macro, rather than having to specify it.

Use case: I have a lot of include paths that include the workspace/repo name, so that it's always clear from looking at an #include statement exactly what header is being referenced. Currently I have to pass the name of the repo to my macro each time so it can do hdrs=glob(['pub/'+reponame+'/'+name+'/*.h'); if I could reliably determine the workspace name, that'd mean less typing and more that could be determined automagically.

---

Related issue, visible with multiple repos:
Assume two repos A and B, and B's WORKSPACE has

local_repository(
    name='anotherNameForA',
    path='../A'
)

If we're in B and run bazel, any targets in A that call native.repository_name() will see the repo name is anotherNameForA regardless of the name declared in repo A's WORKSPACE.

IMO the workspace name should always be the name declared in its workspace file, regardless of how it's named when imported by local_repository rules in another workspace.

At least, there should be some way of retrieving the "real" name even if there is a legit case for altering what native.repository_name()/ctx.workspace_name() report.

[jcpetruzza]

I have the same issue with native.repository_name() returning @. I want to have a macro that generates wrapper-scripts for binary targets, and this requires the binary to be a data dependency of the script. So in order to use rlocation I need the repository name. I've hard-coded it for now, but that makes the macro non-portable.

Incidentally, the title of the issue makes this difficult to find. I spent a while trying to figure out if I was using native.repository_name() wrongly or what :)

[xingao267]

+1 for being able to get the real workspace name from a macro.

[dgp1130]

Ran into this problem myself today (dgp1130/rules_prerender@cc89f55) and had to make some awkward compromises to my desired API to make it work. Are there any objections to adding a new native.workspace_name() function which works identically to ctx.workspace_name() (just returns the name of the current package's workspace)? That would hopefully reduce confusion about the naming discrepancies and allow macros access to the workspace name.

I'm open to making a PR for this if I can at least confirm that this is right path forward. Seems like we just need to add a new workspaceName() method alongside the existing repositoryName() and update the interface accordingly. ctx.workspace_name() seems to get its data from the package, I imagine it's probably not too hard to do the same here. I'm not very familiar with Bazel internals, but hopefully that's all it takes here?

[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.

[dgp1130]

My offer to contribute something here still stands, if anyone can confirm that is indeed the right approach to solve this particular problem and that the contribution would be accepted.

[fmeum]

A number of things have changed since then:

1. When using existing rules (such as in a macro) that support location expansion, $(rlocationpath ...) has been introduced and provides the correct runfiles path without the need to prepend a workspace name.
2. With --enable_bzlmod, the runfiles directory corresponding to the main repository is always called _main, so in the long-term, ctx.workspace_name() will always return that fixed value and probably go away at some point.
3. Also with --enable_bzlmod, there is native.module_name(), which returns the name of the Bazel module defining the current repository.

I would suggest the following "migration guide":

• If you construct runfiles paths in a macro or when using an existing rule, use $(rlocationpath ...) instead.
• If you construct runfiles paths in a custom rule, use file.short_path[len("../):] if file.short_path.startswith("../") else ctx.workspace_name + "/" + file.short_path.
• If you construct labels, use native.repository_name() - the repository name of the main repository is the empty string, so this will always return the correct value for labels.
• If you need some human-readable string identifying the current "context", consider using native.module_name() instead once Bzlmod is enabled by default or use something like native.repository_name() or "<main repository>".

CC @Wyverald

[dgp1130]

Thanks for the recommendations @fmeum. I tried applying this to my usage, but don't see a clear path to it. Specifically your point:

If you construct runfiles paths, use $(rlocationpath ...) instead.

Are there any suggestions for how to handle runfiles paths in APIs where Make variable expansion is not happening? My particular usage of workspace_name is in ctx.actions.write (here) which does not include Make expansion, meaning $(rlocationpath ...) isn't viable.

I suppose I could refactor that into a genrule, though I typically avoid that when generating files because its platform specific and escaping text gets complicated, especially when user input is included in the generated file. That feels like it's moving backwards from a code maintenance perspective. Would the recommended path be "Use an API which includes Make variable expansion" or is there another approach for such situations?

[fmeum]

I updated my comment above to clarify that this only applies when using an existing rule, e.g. in a macro.

When you write your own custom rule, you do have access to ctx.workspace_name, which returns the name of the runfiles directory of the main repository. Your linked approach looks fine to me, I added it to my comment. Why do you need an equivalent of $(rlocationpath ...) in this case?

[dgp1130]

@fmeum, sorry I think I've forgotten a lot of the context here. I remember my original motivation was related to the change in dgp1130/rules_prerender@cc89f55, something about how entry_point needed to be limited to files within the same workspace as the prerender_resources target as specified in the rule docs, but I don't remember exactly how that was fixed by getting workspace names in macros. That API has since been updated so entry_point is always a relative path, so ../../../some_other_wksp/path/to/pkg/file.mjs should work (not that I'd recommend it).

Looking through my existing usages of ctx.workspace_name the only remaining isthis which should be fine because it always points to a file generated in the same rule. I think you're right that ctx.workspace_name is fine there.

Apologies for the noise. 😅

[pauldraper]

Are there any objections to adding a new native.workspace_name() function which works identically to ctx.workspace_name() (just returns the name of the current package's workspace)?

FWIW, repository_name() is the semantically accurate one. (Though bzlmod has changed some things about how useful this really is.)