Fabian Meumertzheim

While this doesn't help in the general case, in the Go case you can just add the Go module with patches to the BCR as a Bazel module and `go_deps`...

> Similar for @shahms, as long as you make sure the tag attribute has type "label", you should be able to pass that label around (in a capability-passing fashion, almost)....

I found a fourth option that I currently like best: 4. Provide a `repo_override` tag on the module extension that accepts a `repo_name` and a list of `targets` and creates...

The visibility of (3) into (1) and (2) (and perhaps even (4)) is something we need to make configurable in some way as part of this issue. The particular case...

@tyler-french's use case is best addressed by an `attr.label` attribute on a tag class. Conveniently, strings of the form `@some_repo_name` are valid labels (shorthand for `@some_repo_name//:some_repo_name`), so the user-facing bits...

> Could the _sees_root_module_repos be _sees_module_repos of a list of REPO(2)s? I may be completely missing some details because our team is new to bazel. I am presuming that root...

@rkallal This sounds like a request to add support for arbitrary repo rules as `source.json` type, which isn't necessarily related to repo visibility. Could you create a separate issue for...

While writing a module extension that instantiates repos with user-supplied BUILD files, I used the following replacement for `repo_override`: I added an `attr.label_list()` called `bazel_dep` that accepts labels of the...

If we decouple "overriding a repo definition" from "modifying a repo's repo mapping", we may be able to realize a cleaner API for the latter. This is a concept with...

Should this be cherry-picked into 7.0.1?