Allow --override_repository to accept apparent repo names (as seen from the main repo), in addition to canonical repo names

[keith]

Description of the bug:

If you have a module extension with bzlmod that loads arbitrary http_archives like:

use_repo(
    deps,
    "Yams",
...

you cannot override it with --override_module because of the capital letter:

--override_module=Yams=/Users/ksmiley/dev/Yams:

ERROR: While parsing option --override_module=Yams=/Users/ksmiley/dev/Yams: invalid module name 'Yams': valid names must 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit.

Using ---override_repository also has no affect.

I'm not sure if the bug here is that these names should be allowed, or if there should be a different way to override these

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

6.0.0rc4

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

No response

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

No response

Have you found anything relevant by searching the web?

No response

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

No response

[keith]

This also doesn't work if you use local_path_override

[keith]

in a quick test just allowing uppercase module names also doesn't work, but i imagine they could be being transformed elsewhere as well.

[Wyverald]

"Yams" here isn't a module -- it's not from a registry, doesn't participate in version resolution, etc. You can use --override_repository, but with the canonical repo name only (_main~$EXTENSION_NAME~Yams)

[keith]

Good to have that workaround. Is this something you plan to improve?

[Wyverald]

Hmm... I think one way to improve this might be to let --override_repository accept keys that start with either @ or @@, similar to how labels are specified on the command line. So --override_repository=_main~$EXTENSION_NAME~Yams=dir is equivalent to --override_repository=@@_main~$EXTENSION_NAME~Yams=dir or --override_repository=@Yams=dir (the singular @ makes it go through the main repo mapping).

[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 30 days. It will be closed in the next 7 days unless any other activity occurs or the "not stale" label is added.

[brentleyjones]

@keertk not stale, triaged and not waiting for input

[iancha1992]

@bazel-io fork 7.0.0

[Wyverald]

After taking a brief look, I realized that this is actually surprisingly annoying to implement. This would be a rare flag that influences repo fetching / Bzlmod resolution, but also relies on the result of repo fetching / Bzlmod resolution (calculating the main repo mapping might require 'fetching' bazel_tools, for example).

We could make --override_repository one of those flags that get re-parsed after main repo mapping is computed, but this has multiple downsides: 1) the main repo mapping is only computed for commands that "build", which excludes fetch, sync, etc -- whose behaviors should be affected by --override_repository; 2) the option re-parsing step actually happens way after BlazeModule#beforeCommand, but all the repo options are initialized in BazelRepositoryModule#beforeCommand.

Alternatively, we could somehow remember that some apparent repo names were passed to --override_repository, and only resolve them in RepositoryDelegatorFunction. The problem is, though, that RDF only knows about the canonical repo name; it's potentially possible for RDF to request the main repo mapping, but that's incredibly convoluted and things are very likely to go wrong if we do it this way.

So I'm going to remove this from the 7.0 blockers and maybe tackle it in the future instead.