Convert WORKSPACE to MODULE.bazel, update README #312
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rather than mess with the WORKSPACE rules, the shortest path to fixing `blaze build //swift:tests` appeared to be introducing MODULE.bazel. MODULE.bazel, a.k.a. bzlmod, appears to be the new hotness, so I'll also try updating the other builds to use it as well. - https://bazel.build/external/migration - https://bazel.build/external/overview#workspace-shortcomings - bazelbuild/bazel#18958
Also bumps to: - protobuf: 23.1 - rules_proto: 6.0.0-rc2
rules_java was an implicit dependency before. Bumps: - rules_java: 7.4.0 => 7.5.0. - rules_jvm_external: 4.4.2 => 6.0 The rules_jvm_external docs describe using `maven.install` in MODULE.bazel as a replacement for `maven_install` in WORKSPACE: - https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/bzlmod.md However, our current `maven_install` depends on the definition of IO_GRPC_GRPC_JAVA_ARTIFACTS from @io_grpc_grpc_java. I'll attempt that migration next.
`bazel build //java/...` and `bazel test //java/...` both work with these changes.
grpc-java only got MODULE.bazel support as of this most recent version: - grpc/grpc-java#11046 - bazelbuild/bazel-central-registry#1699 This grpc-java version bump exposed two issues that are fixed in this commit: 1. The //java/com/engflow/notificationqueue:client target dependency on @maven//:io_netty_netty_handler broke. The original WORKSPACE import of io_grpc_grpc_java imported this dependency directly by passing IO_GRPC_GRPC_JAVA_ARTIFACTS directly to `maven_install`. The `maven.install` call from grpc/grpc-java's MODULE.bazel sets `strict_visibility = True`. Somehow the other dependencies registered by grpc-java's MODULE.bazel are accessible to notificationqueue:client, but netty-handler isn't. The solution was to add the `io.netty:netty-handler:4.1.100.Final` artifact to the `maven.install` call in this project's MODULE.bazel. It doesn't seem an optimal solution, but it works for now. 2. grpc/grpc-java removed `io.grpc.stub.MetadataUtils.attachHeaders()` in grpc/grpc-java#10443. This caused notificationqueue:client to fail to compile, but that PR revealed the replacement for the deprecated `attachHeaders` call. This commit applies that replacement.
This appears to be a fairly recent development, and isn't yet 100% officially supported in the googleapis/googleapis repo, but it works: - googleapis/googleapis#855 - bazelbuild/bazel-central-registry#1699
There's actually a 0.2.1 release, but it hasn't been pushed to https://registry.bazel.build/ yet.
rules_scala hasn't migrated to bzlmod yet, but discussion is underway. These links will help track its progress.
This enables `bazel {build,test} //infra/...` to succeed using
MODULE.bazel. See:
- https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md#specifying-external-dependencies
This eliminates warnings that these tests are sized too big, since the default is "medium".
This moves the following http_file calls: - emacs - ubuntu_20.04_1.3GB and the following http_archive calls: - com_engflow_engflowapis - io_abseil_py
The //dotnet/toolchain constraint was causing a Bazel error saying that the @@rules_dotnet//dontent/toolchain package didn't exist. Removing this constraint allowed remote execution to succeed anyway.
Most of these changes are cosmetic, with the notable exception of the explantion behind the inability to build //swift remotely. Also added a `git` command to ignore python/requirements_lock.txt per: - https://stackoverflow.com/a/73720550
jayconrod
approved these changes
Apr 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Inspired by https://github.com/EngFlow/engflow/pull/20913#discussion_r1559691958 by @jayconrod.
If this PR is too large, I'm happy to break it up. I also don't know yet how this will affect dependabot, so I'm happy to research that first if need be.
Rather than mess with the WORKSPACE rules, the shortest path to fixing
blaze build //swift:testsappeared to be introducing MODULE.bazel.MODULE.bazel, a.k.a. bzlmod, appears to be the new hotness, so I updated the other builds to use it as well.
--enable_bzlmodto true bazelbuild/bazel#18958The only one that isn't ready is
//scala. rules_scala hasn't migrated to bzlmod yet, but discussion is underway.Finally,
//swiftstill won't build remotely, for the reasons cited here: