Skip to content

Modules obtained from registries should fall back to copying MODULE.bazel from the registry #26217

@gholms

Description

@gholms
Contributor

Description of the feature request:

For modules representing projects which lack MODULE.bazel files, module maintainers have to carry patch files or overlay/MODULE.bazel symlinks so http_archive and friends take care of injecting them into repos. Since the registry already needs to contain MODULE.bazel anyway, this amounts to needless busywork for nearly every module in the BCR. When a module comes from a registry, bazel should fall back to copying or symlinking the MODULE.bazel file it got from the registry if none exists after repository rules finish.

Which category does this issue belong to?

External Dependency

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

Needless busywork for most modules' maintainers.

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 7.6.1

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 HEAD ?


Have you found anything relevant by searching the web?

No response

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

No response

Activity

added
P3We're not considering working on this, but happy to review a PR. (No assignee)
team-ExternalDepsExternal dependency handling, remote repositiories, WORKSPACE file.
and removed on Jun 3, 2025
Wyverald

Wyverald commented on Jun 18, 2025

@Wyverald
Member

It just occurred to me today that this could be implemented fairly simply by just treating the MODULE.bazel file served from the registry as an implicit overlay. That is, whenever we generate a RepoSpec for a module using http_archive (code), always set the MODULE.bazel file from the registry as a remote_file_url.

Of course, this means that we need to add overlay support to git_repository to be fully on par -- but that shouldn't be hard.

self-assigned this
on Jun 18, 2025
added
P1I'll work on this now. (Assignee required)
and removed
P3We're not considering working on this, but happy to review a PR. (No assignee)
on Jun 18, 2025
fmeum

fmeum commented on Jun 18, 2025

@fmeum
Collaborator

I tried this in #26332, but this fails on modules with patches applied to the module file to please the very check we want to remove.

fmeum

fmeum commented on Jun 18, 2025

@fmeum
Collaborator

Looks like we can get around this by swapping the order in which http_archive applies patches and overlays - how breaking would you consider that?

Wyverald

Wyverald commented on Jun 18, 2025

@Wyverald
Member

hmm, that's a bit annoying. The order of "overlays before patches" is explicitly documented at https://bazel.build/external/registry#source-json, so it would be fairly breaking. Maybe we do need a dedicated remote_module_file attribute on http_archive after all. (Can also remove the workspace_file and workspace_file_contents attributes by now.)

added a commit that references this issue on Jul 1, 2025
c5a562b
added a commit that references this issue on Jul 2, 2025
304ec27
added a commit that references this issue on Jul 8, 2025
9541980
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1I'll work on this now. (Assignee required)team-ExternalDepsExternal dependency handling, remote repositiories, WORKSPACE file.type: feature request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Participants

    @gholms@Wyverald@fmeum@sgowroji@iancha1992

    Issue actions

      Modules obtained from registries should fall back to copying MODULE.bazel from the registry · Issue #26217 · bazelbuild/bazel