Initial bzlmod support

[jsharpe]

[jsharpe]

This isn't working at the moment - it fails to find the registered toolchain.

[fmeum]

@jsharpe I think that you are hitting https://github.com/bazelbuild/bazel/issues/16607. If I comment out the platforms http_archive in repositories.bzl, the toolchain is found.

Before:

$ bazel query @local_cuda//toolchain/clang:clang-local-toolchain --output=build --enable_bzlmod
toolchain(
  name = "clang-local-toolchain",
  visibility = ["//visibility:public"],
  exec_compatible_with = ["@~ext~platforms//cpu:x86_64"],
  toolchain_type = "//cuda:toolchain_type",
  target_compatible_with = ["@~ext~platforms//cpu:x86_64"],
  target_settings = ["//cuda:is_enabled", "//cuda:compiler_is_clang"],
  toolchain = "@~ext~local_cuda//toolchain/clang:clang-local",
)

After:

$ bazel query @local_cuda//toolchain/clang:clang-local-toolchain --output=build --enable_bzlmod
toolchain(
  name = "clang-local-toolchain",
  visibility = ["//visibility:public"],
  exec_compatible_with = ["@platforms~0.0.4//cpu:x86_64"],
  toolchain_type = "//cuda:toolchain_type",
  target_compatible_with = ["@platforms~0.0.4//cpu:x86_64"],
  target_settings = ["//cuda:is_enabled", "//cuda:compiler_is_clang"],
  toolchain = "@~ext~local_cuda//toolchain/clang:clang-local",
)

[Wyverald]

The problem is here: https://github.com/bazel-contrib/rules_cuda/blob/8a515347af61a83187c4dbf700aa1f96c0575639/cuda/private/repositories.bzl#L176

This generates a BUILD file inside @@~ext~local_cuda, using a template that contains these lines: https://github.com/bazel-contrib/rules_cuda/blob/8a515347af61a83187c4dbf700aa1f96c0575639/cuda/templates/BUILD.local_toolchain_clang#L34-L39

While it's true that nobody's use_repoing @@~ext~platforms, this repo is still visible to all the repos generated by the same extension under its declared name (platforms). This name binding intentionally has higher priority than @@platforms~0.0.4 (see logic at https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/RepositoryMappingFunction.java;l=198-204;drc=bdcd65d878dc7aff006a5c6d86268d76b536c9a5)

The fix should be simple -- instead of calling rules_cuda_dependencies() in your module extension, just call local_cuda(name = "local_cuda").

[meteorcloudy]

@Wyverald I don't think we need to fix anything from Bazel side, but maybe we can give some warnings if any well-known repos are generated by module extensions? Especially, platforms, and other repos containing platform and toolchain definitions, otherwise, there could be easily mysterious mismatching errors.

[cloudhan]

I don't think we need to fix anything from Bazel side

I think the spooky action at a distance must be eliminated.

[Wyverald]

It's unclear how this could be "fixed", which is why we defined the behavior to be "prioritize the generated repo over the bazel_dep of the hosting module". Any ideas would be welcome.

[fmeum]

@Wyverald I like @meteorcloudy's idea to issue a warning if a module extension contains a repo that shadows a bazel_dep's repo_name. At least if we don't see valid use cases for this.

[jsharpe]

TODO: need to add a CI job to build with bzlmod enabled

[jsharpe]

@ryanleary one thing this will change about the release process is a need to bump the version number in MODULE.bazel as part of the release process. I've not looked at the release scripts in detail to know how to do this automatically. Would this be easy to add?