Implement "Locating runfiles with Bzlmod" proposal

[fmeum]

The "Locating runfiles with Bzlmod" proposal consists of the following individual steps:

• [x] ~Add the RunfilesLibraryInfo provider (#16125)~
• [x] Collect repository names and mappings of the transitive closure of a target (#16278)
• [ ] Emit a repository mapping manifest for every executable
• [ ] Expose the current repository name in rules for compiled languages
  • [x] C++ (#16216)
  • [ ] Java (#16281)
• [ ] Parse and use the repository mapping manifest in runfiles libraries (https://github.com/bazelbuild/bazel/issues/15029)
  • [ ] Bash
  • [ ] C++
  • [ ] Java
  • [ ] Python
• [ ] Use the Java runfiles library to make Stardoc work with repository mappings (https://github.com/bazelbuild/bazel/issues/14140)

[fmeum]

@Wyverald Could you assign me and add the appropriate labels?

[fmeum]

~~@comius Do you expect java_binary to be starlarkified in time for Bazel 6? That would simplify the changes to the Java rules.~~ Most likely no longer necessary, as the changes will apply to buildjar itself.

[fmeum]

@Wyverald Oops, I missed the use of Closes ... in the PR description - we should use Work towards ... instead. Could you reopen? For some I lack the permission to do so.

[Wyverald]

It's the "To fix #NNN" line... GitHub trying to be clever here

[lberki]

The most likely future seems to be that we'll standardize on Python imports not containing the repository name, in which case bzlmod is a no-op.

It's not an optimal solution because it requires an entry in $PYTHONPATH for each repository in the transitive closure of the Python binary, but it's the status quo and I'd much prefer thinking up a solution to that (e.g. binary-specific symlink trees that do not look like runfiles trees, dunno) than to standardize on having the repository names in imports because the concept of "repository" is specific to Bazel.

Put differently: the only way for bzlmod to cause trouble for Python is if we decide to require repository names in imports, which seems to be unlikely and it looks like the decision on that will take a while and I prefer not blocking either Bazel 6.0 or the removal of bzlmod from the experimental domain to avoid an unlikely failure mode. And should that happen, we can always paper over it with some sort of import hook.

/cc @rickeylev

[fmeum]

@oquenchil I'm thinking about whether we should use a macro to pass BAZEL_CURRENT_REPOSITORY to the Rlocation function automatically (e.g. do #define Rlocation(path) RlocationReal(path, BAZEL_CURRENT_REPOSITORY)). Do you think that would be too intrusive/magical?

[oquenchil]

Would users have to write that line or is it part of a file that is automatically generated?

I don't mind adding whatever will make it easier but if it gets too magical it should maybe be wrapped so that the details aren't visible to the user unless they want to look.

[fmeum]

Would users have to write that line or is it part of a file that is automatically generated?

I don't mind adding whatever will make it easier but if it gets too magical it should maybe be wrapped so that the details aren't visible to the user unless they want to look.

@oquenchil I would want to make that magic part of the runfiles library header so that users don't have to write it themselves.

What I am worried about is having an Rlocation macro mess with people's existing codebase since there doesn't seem to be a way to put it in a namespace or restrict it to member functions only.

[oquenchil]

Aren't we in control of the name of the macro? Can we rename it to something that would be very unlikely to clash with anything?

[fmeum]

Aren't we in control of the name of the macro? Can we rename it to something that would be very unlikely to clash with anything?

We can call it something else, we just won't be able to have existing C++ codebases use the new repo mapping-aware lookup automatically if we do so. But of course having to replace all runfiles::create() calls with something else won't be too bad.

[oquenchil]

If the macro name is Rlocation and that may start clashing with people's code in C++ files then I think it would be prudent to rename it if we decide to go with the macro.

I guess the call to make here is how much of a breaking change this is compared to the benefit of passing BAZEL_CURRENT_REPOSITORY automatically for users. I would say that the benefit is not too great but as far as I understood the use of Bazel runfiles in C++ code wasn't too wide-spread either?

But of course having to replace all runfiles::create() calls with something else won't be too bad.

How do you know? Is it based on search results from GH? If a release note would be enough for it not to be too disruptive then let's rename it.

[fmeum]

I have experimented a bit more with APIs while working on the corresponding change for Java (https://github.com/bazelbuild/bazel/pull/16549).

What I now like more than the macro approach is to have users (optionally) pass in a canonical repository name when creating the Runfiles instance and default to that repo in Rlocation calls, while providing ways to override the default with an overload of Rlocation that accepts a repository name as a second parameter. In this way, users only have to pass in BAZEL_CURRENT_REPOSITORY only once in the common case, which should render a macro unnecessary.

[fmeum]

Update: All changes relevant for Bazel 6.0.0 are now in review.

[fmeum]

This is mostly done now, with only the bugfix https://github.com/bazelbuild/bazel/pull/16755 and a number of cherry-picks to 6.0.0 missing.

[fmeum]

@Wyverald You can remove this from the "6.0.0 nice to have" milestone as the only remaining issue is not tied to a Bazel release (Stardoc).

[Wyverald]

Downgrading because the most important points have been addressed; the only outstanding issue is Stardoc, which is undergoing a rewrite currently by @tetromino.