bazelbuild
There's no way to segment a `MODULE.bazel` file
Description of the problem / feature request:
In large repos with many languages and external third party dependencies, the MODULE.bazel file will grow in an unbounded way. In addition, because it's only available at the root of a workspace, it's not possible to segment it in such a way that GitHub code owners can review the sub-section of the MODULE.bazel file they are most comfortable with (eg. in a monorepo, it would be convenient to have a subsection of the MODULE.bazel file under //java and another under //go so that they can be reviewed individually by code owners of those sub-trees)
Since we want to avoid using load for obvious reasons, perhaps import and try_import functions could be added? These would be analogous to the import and try-import statements in .bazelrc.
Feature requests: what underlying problem are you trying to solve with this feature?
I want the top-level MODULE.bazel file to not be overwhelming to read and deal with.
I would like code owners to be able to take ownership of subsections of the module using GitHub's native "code owners" feature.
What's the output of bazel info release?
5.0.0
I think we could actually allow load for top-level projects (a.k.a root modules) only. I'm also somewhat partial to the include/import solution in favor of loading a macro, since using native.X is really unwieldy.
cc @brandjon
I think this may need to work in projects that aren't the top-level too. Perhaps limited to importing files that are in the current project being evaluated?
That would mean that registries also need to store more files than just MODULE.bazel, which I would really like to avoid.
The MODULE.bazel uploaded to the registry could be the output of merging all the local input files (a bit like uploading the output of a pre-processor) Because load still isn't allowed, the output should be deterministic.
Hmm, indeed -- that's actually an argument in favor of "import" vs "load a macro and call it".
After some implementation work and discussion, I don't think this is feasible.
The gist of the problem is that segmenting the file gives the impression that each file can function independently, but that's not actually true. For example, if two segments both declare a bazel_dep on the same module, we'd just error out since a module can't depend on the same module twice (without a multiple-version override, that is).
One might be tempted to say "just pick the highest version". At that point, there's no different between this and having sub-modules (having a subdirectory tree represent a separate module). And submodules are much more robust in terms of semantics.
And the problem goes beyond that. What if segment A declares bazel_dep([email protected], repo_name="foo"), and segment B declares bazel_dep([email protected], repo_name="foo")? There is necessarily an error here because uses of the repo name "foo" conflict with each other here, and there's no easy way out. This means that having different code owners for different segments is a somewhat empty promise, since owners of one segment still need to be careful not to step on the toes of other segments.
There is indeed a parallel with import in .bazelrc files, but that statement is usually used to import user-defined RC files, instead of segmenting a long config file. There's much less of a need to import a "user-defined segment of MODULE.bazel directives".
@Wyverald reopen please?
This feature is kind of important for a large repo in terms of separation of concerns -- third party dependency management is always delegated to language-based experts -- having this file segmented will allow common review configs (eg. OWNERS file) to continue work.
See https://github.com/bazelbuild/bazel/issues/17880 for a more recent issue.
third party dependency management is always delegated to language-based experts -- having this file segmented will allow common review configs (eg. OWNERS file) to continue work.
The big problem there is -- what if you have two bazel_deps on the same module, but specified in different files? That's where the OWNERS model would likely break down, one way or another.