use_repo name remapping limits the space of possible target workspace names

[aherrmann]

Description of the feature request:

use_repo, called in MODULE.bazel to import an external workspace generated by a module extension, supports name remapping using keyword argument syntax. E.g. if the module extension ext generates the external workspace foo then I can rename it to bar using the syntax

use_repo(ext, bar = "foo")

This limits the space of possible target names to those names which are valid Starlark identifiers. In particular, it is not possible to remap the workspace to the name bar-baz, because it is not a valid Starlark identifier, i.e. the following causes an error

use_repo(ext, bar-baz = "foo")

However, bar-baz would be a legal name for an external workspace and @bar-baz//:xyz would be a valid label. And other forms of repo name remapping do support the full range of possible workspace names, e.g. via the bazel_dep repo_name parameter which accepts a string. Making this limitation seem like an inconsistency.

Please support repo name remapping to the full range of possible workspace names for module extension generated workspaces.

Which category does this issue belong to?

External Dependency

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

I am trying to map old usage patterns under the WORKSPACE and repository rule system to bzlmod using isolated extensions and repo name remapping. See tweag/gazelle_cabal#61. In particular, I am trying to remap an external workspace generated by a module extension named stackage-exe to the name stackage-b-exe.

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

release 6.2.0- (@non-git)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

Nix

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

n/a

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

Bazel Slack discussion.
This kind of name remapping was possible using kwargs until 7a262a6, thanks @fmeum for the pointer.

[fmeum]

I don't have any better idea than selectively allowing **kwargs in MODULE.bazel files and recommending them for this use case.

[aherrmann]

Other options that come to mind:

• Address the limitation at the syntax level, e.g. allow use_repo(ext, "bar-baz" = "foo") or similar.
  (Seems like potentially a major effort if it has to go through a formal Starlark language change).
• Provide some other interface for remapping,
  • e.g. rename_repo("foo", "bar-baz")
    (Seems problematic, as it can be hard to spot the correct name for a repo when this call is far away from the import site)
  • or use_repo(ext, "foo", repo_names = ["bar-baz"])

[fmeum]

One more alternative would be to accept pairs as positional arguments: use_repo(ext, ("bar-baz", "foo"))

[Wyverald]

I was also thinking of just allowing a map to be passed, like use_repo(ext, {"bar-baz":"foo", "something.else":"bar"}). It'd require some finagling of the @StarlarkMethod machinery but should be doable.

[aherrmann]

Nice, I like the dict option.

[luispadron]

Personal opinion here is that I found the kwarg based API a bit clunky, could we improve this somehow, maybe with structs?

+1 to dict, or some escape hatch. As a "practical" example, I tried to use override_repo (which suffers from this same issue) with swift-syntax and that doesn't work because - fails Starlark parsing.

[fmeum]

For override_repo, you can use repo_name on the dep to rename it to something supported by override_repo. That requires changing all other references to it in your BUILD files, but it is an escape hatch that exists today.

Edit: Ignore this, it's the wrong way round. @luispadron Are you referring to overriding a repo swift-syntax in a module extension rather than overriding with the swift-syntax Bazel module?

[luispadron]

@fmeum We discussed and fixed (thank you) the swift-syntax case over in #23981.

I do think this issue is still valid, repo_name is a good alternative for now though but ideally it just works