Support Bzlmod and add rules_scala to bazel-central-registry

[sfc-gh-pbennes]

Greetings!

It looks like rules_scala isn't part of the Bzlmod effort or added to bazel-central-registry yet. I've opened an issue both here and in https://github.com/bazelbuild/bazel-central-registry to request it: bazelbuild/bazel-central-registry#522

[mbland]

A quick update for visibility: I'm very close to having the Bzlmodified rules_scala passing 100% of the tests, down to the last couple of failures:

• I need to replace the bind() calls from twitter_scrooge with alias() or some such to get test_version.sh to pass.
• I need to fix the Scala 3.1.2 and Scala 3.3.3 failures for the Scalafmt targets from test/shell/test_cross_build.sh (corresponding to the test3 and library3 test cases in test_scalafmt()).

I also need to get test_lint.sh working again, and update the dt_patches repos for Bzlmod. But the following all pass:

• test_rules_scala.sh
• test_reproducibility.sh
• test_examples.sh
• test_coverage.sh

Hopefully I can get these fixed up today, and I'll start peeling off the next pull request or two. And thanks to @simuons and @liucijus for reviewing and merging #1619 and #1620 already.

[liucijus]

• I need to replace the bind() calls from twitter_scrooge with alias() or some such to get test_version.sh to pass.

If I recall correctly, scrooge rules support dep configuration via toolchain. I think we should purge the outdated use of bind() in favor of using toolchains. alias() creates new label in the current workspace, it won't allow to replace external names.

[mbland]

BTW, I ended up getting ./test_lint.sh back in shape, and got all the dt_patches stuff working with Bzlmod, except for one test case when passing in a label to a compiler srcjar. Try bazel build //... --repo_env=SCALA_VERSION=2.12.16 //... inside dt_patches/test_dt_patches_user_srcjar to see what I mean.

FWIW, the test_compiler_patch 2.13.0 case from dt_patches/dt_test_patches.sh also fails on master under WORKSPACE. So I wonder if it's worth commenting out that case.

After that, I think it's just the bind() and Scala 3 + Scalafmt issues I mentioned earlier that are standing in the way. Hoping to tackle those this weekend.

[BillyAutrey]

After that, I think it's just the bind() and Scala 3 + Scalafmt issues I mentioned earlier that are standing in the way. Hoping to tackle those this weekend.

Let me know if this becomes an issue, I'm coincidentally dealing with related fun for other crossbuild reasons.

[mbland]

Got everything working now except the test/shell/test_cross_build.sh failures for Scala 3 + Scalafmt.

I also fixed the test_compiler_patch 2.13.0 case from dt_patches/dt_test_patches.sh, FWIW.

@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

[agluszak]

You're a hero, @mbland!

[agluszak]

Btw I really enjoy reading your commit messages in https://github.com/mbland/rules_scala/commits/bzlmod/ :)

[mbland]

Heh, I just explained to someone recently that that my choice for the top line format started as me thinking that I'd only have a few commits that I'd squash. Then after I realized what I got myself into, I kept the gag going to maintain my sanity. I'm definitely going to have top line descriptions when I send the actual pull requests.

[mbland]

OK, got Scalafmt working with Scala 3. So that's it; everything's working now and all the tests pass.

I'll start pulling off pieces and cleaning them up for separate pull requests. I'm expecting a bit of discussion and refactoring around several pieces, but at least I've got a working branch in hand.

[liucijus]

@liucijus I can see a path to ripping out the bind() calls while maintaining WORKSPACE compatibility, if you'd like me to try that. I'm not currently planning to do it in my bzlmod working branch, but could do it when I create a pull request to Bzlmodify twitter_scrooge specifically.

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

[agluszak]

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Imho yes, let's not block bzlmodification on niche features:)

[mbland]

I guess it's not worth spending a lot of time on scrooge - I'm not even sure how many users we have, it feels outdated.

Imho yes, let's not block bzlmodification on niche features:)

Well, I do have it working under Bzlmod already. I just didn't plan on ripping out bind() entirely until I migrate that piece in its own PR.

[mbland]

@liucijus @simuons Let me know if I'm sending too many PRs too quickly and if I should start holding some back. Up to this point, they're largely orthogonal and can go in in any order, but I'm getting to the point where some changes will depend on earlier PRs. (I can always rebase the future PRs, if you don't mind me running ahead.)

Also, please check out #1625 that I filed today. We're kind of stuck with the "Bazel green head" job failing in a way that breaks our builds due to the problem I described there.

[mbland]

More updates! Thanks to @simuons merging #1627, my currently outstanding PRs all pass (#1621, #1622, #1623, #1624, #1626), including the "Bazel latest" job (currently 7.3.2).

I'll hold off on sending new PRs until those are merged, but I've got quite a few lined up. Here are my branches containing more orthogonal changes that can land in any order:

• bzlmod-sync-bazelversion: Contains a script to generate and update .bazelversion files in nested repos. Not so much an issue in CI, but can be surprising when developing locally.
• bzlmod-extraprotobufgenerator-catch-throwable: Updates ExtraProtobufGenerator to log errors that would previously crash a protoc-bridge worker and hang the build. This led to a fix, included in the bzlmod-fix-proto-hanging below.
• bzlmod-update-scalafmt-deps: Bumps Scalafmt to 3.8.3 to avoid breakage on Scala 2.13 and up, matched with the proper Scalameta version 4.9.9 to resolve Scala 3 hilarity. Also adds a ScalafmtAdapter for API diffs with Scalafmt 2.7.5, required for Scala 2.11.

After those, I'd like to land the following (after some more work and cleaning up) in order to update gRPC dependencies and enable Bzlmod clients to use protobuf > v21.7:

• bzlmod-update-protocbridge-and-grpc: Contains changes to accommodate some minor API updates.
• bzlmod-fix-proto-hanging: Building on Bump to rules_proto 6.0.2, separate protobuf 21.7 #1623 and bzlmod-extraprotobufgenerator-catch-throwable, this currently bumps abseil-cpp, protobuf, and rules_cc to latest to reproduce/diagnose the previous ProtoScalaPBRule aspect worker hang. Then bumps ScalaPB JARs to 1.0.0-alpha.1 to fix it. Since we want to maintain Bazel 6 compatibility for now, though, I won't commit the actual protobuf and abseil-cpp updates until later.

I'll start breaking off the actual toolchainization pieces now, since I think I've got a handle on all of the other problems with these other PRs and branches.

While I'm going through, I'm also replacing @io_bazel_rules_scala references with either //... paths or Label("//...") instances (in legacy macros— the new symbolic macros coming in Bazel 8 look like a lot of fun!), so Bzlmod consumers won't need to specify repo_name = "io_bazel_rules_scala" in their bazel_dep() directives. This may require a dedicated cleanup PR at some point.

As I've mentioned before, I'm being methodical about solving all the problems I can before landing the actual MODULE.bazel file and module extensions to ensure WORKSPACE and Bazel 6 compatibility. While I'm doing this, I'm building locally with the latest mainline Bazel and patching things into my Bzlmod working branch. Then the Bzlmod parts will essentially land as a thin layer on top.

[mbland]

I've managed to extract //scala:toolchain_type toolchains into a new repo as a separate, WORKSPACE compatible change from the rest of my bzlmod working branch. The other toolchains should be even easier to break off, after this first change is in place.

Right now, that commit and the bzlmod-toolchain-scala branch are based on all the open PRs and changes from other pending branches, but it's otherwise self-contained. I can try rebasing it directly on master in the morning.

[agluszak]

@mbland, let me repeat that: you're THE hero!

[mbland]

@mbland, let me repeat that: you're THE hero!

Heh, I appreciate the sentiment, but I don't believe there's any heroics in programming. 🙂 On the contrary, I'm fortunate to be able to work on a problem that's interesting to me, and to get paid to do it.

[mbland]

I updated #1633 to create a new scala_toolchains() macro to provide a common mechanism between WORKSPACE and Bzlmod for configuring and generating a toolchains repo. The other macros are still in place, and compatible with existing WORKSPACE usage, for folks that don't want to switch to scala_toolchains(). But they'll have to add scala_toolchains_repo() to their existing WORKSPACE config in that case.

I've got both WORKSPACE and Bzlmod builds working in my bzlmod working branch now with the changes from #1633 merged in, at least under Bazel 7.4.0. Will try 6.5.0 tomorrow. (I'll use scripts/sync-bazelversion.sh for that. And I had fun hacking together a nifty script for switching between WORKSPACE and Bzlmod to make this process easier.)

I've ripped out the native.bind() calls from twitter_scrooge/twitter_scrooge.bzl. Everything passes, even under WORKSPACE.

Thanks to @simuons for all the thoughtful code reviews and improvements over the past week or so, and @WojciechMazur for jumping in and suggesting improvements as well.

Update: Confirmed everything works with WORKSPACE and Bzlmod builds using Bazel 6.5.0 as well.

[zcking]

@mbland Not all heroes wear capes 🦸 ! Can't thank you enough for reviving this issue and leading the effort to support Bzlmod.

I'm not a long-standing Bazel user and Bzlmod is so much simpler to use IMO. That said, lack of Scala support is literally the only thing keeping me from making the switch from sbt, and now my hope is restored.

Any ETA on a final release? 🙏

[mbland]

Again, I deeply appreciate the appreciation, but these have been helpful contributions, not heroism. 🙂 I'm compelled to push back politely on such characterizations, however honored I am to receive them.

To answer your question, though, I'm hoping we can land the remaining Bzlmodification changes quite soon.

---

That said, it's up to the time and bandwidth @simuons and @liucijus have to review the pull requests, whether they have any concerns and/or suggestions, and when they're comfortable cutting a release after that. They've been incredibly helpful and responsive to date, and I'm not trying to rush them. Several of the changes have benefitted substantially from review feedback, including several receiving serendipitous feedback from @WojciechMazur. (Plus, I indirectly roped @fmeum into effectively reviewing #1621 via bazelbuild/bazel-skylib#548. I'm so glad I did, because the end result was so much better.)

As I've been fond of telling people recently, this is Open Source at its best, working as intended. 🙂

Once #1633 gets reviewed, possibly updated, approved, and merged, that will clear the way for the rest of the essential Bzlmodification/toolchainization changes. My comments in #1633 explain what I'm shooting for, and link to the working prototype in my Bzlmod working branch—which now also maintains WORKSPACE compatibility. So hopefully the complete Bzlmodification itself will land quickly.

---

While I'm at it, let me recap the other activity related to this effort.

Most of the changes so far have been in preparation for landing the essential Bzlmodification/toolchainification changes, the first of which being #1633. Some have been essential prerequisites, fixing things that outright break under Bzlmod, such as #1621 or #1626. But with those fixed, now we're talking about providing a proper Bzlmod API that doesn't put the burden on users to import dozens of repos required by rules_scala toolchains (such as I had to do in the current MODULE.bazel from EngFlow/example). Technically, #1635 falls in this API design category as well.

Other pull requests have addressed small compatibility issues I've encountered along the way, like Bazel 7 compatibility in #1619 and #1620; Bzlmod compatible testing in #1622; and Scala version compatibility in #1628, #1632, and #1634. I've included a couple of helpful utilities I've written as well in #1629 and #1638. All of these should make maintaining the implementation and switching to Bzlmod even smoother, by resolving existing problems before anyone else encounters them.

I've also been identifying and making changes to ensure users aren't version locked on any dependencies thanks to rules_scala, such as #1631 (which was borderline essential, because Scalafmt 3.0.0 threw java.util.NoSuchElementException: last of empty IndexedSeq under Scala 2.13). I'm now focusing on trying to ensure more recent Protobuf module versions work with the scala_proto toolchain and with aspects implemented using protobuf/gRPC/ScalaPB/protoc-bridge (including the Scalafmt aspect). This is where changes like #1623, #1624, #1630, and #1637 come from. Much of that effort involves coordinating version bumps in the jar dictionaries from the third_party/repository/scala_*.bzl files and adding API adapters for specific Scala and/or dependency versions as needed. (Updating those dictionaries manually is why I'm also investing in updating scripts/create_repository.py in #1639, because doing all that work by hand in #1631 was the most time consuming part of this effort to date.)

---

Anywho, there's a few more changes to come, for Bzlmodification itself, for Protobuf upgradability, and for internal test and tooling updates. But as I've told friends and colleagues, I'm beyond seeing the light at the end of the tunnel. I'm out of the tunnel, off of the highway, and in the neighborhood, around the corner from the destination, turning the radio down so I can focus on where to park. 😛

[sundbry]

For my $0.02, I've checked out your mbland/bzlmod scala branch, and used it to build some scala programs - it works great! Thank you very much for pushing this code upstream.

The only issue I had, and I don't think this was related to your changes in particular, was figuring out how to set it up to use the scala3 toolchain- I ended up using --repo_env=SCALA_VERSION=3.4.3 in the build command to set it, but couldn't figure out how to set it in the MODULE.bazel or BUILD.bazel with the new configuration.

[mbland]

For my $0.02, I've checked out your mbland/bzlmod scala branch, and used it to build some scala programs - it works great! Thank you very much for pushing this code upstream.

My pleasure!

The only issue I had, and I don't think this was related to your changes in particular, was figuring out how to set it up to use the scala3 toolchain- I ended up using --repo_env=SCALA_VERSION=3.4.3 in the build command to set it, but couldn't figure out how to set it in the MODULE.bazel or BUILD.bazel with the new configuration.

Ah—my MODULE.bazel from EngFlow/example has an example of what this will look like. The only difference is the extension path will be @rules_scala//scala/extensions:config.bzl:

# This constant matches the default Scala version from rules_scala for now.
SCALA_VERSION = "2.13.12"
SCALA_VERSIONS = [SCALA_VERSION]

scala_config = use_extension("//scala/extensions:config.bzl", "scala_config")
scala_config.settings(
    scala_version = SCALA_VERSION,
    scala_versions = SCALA_VERSIONS,
)

Using named constants is optional, of course. Also, in this case, the SCALA_VERSIONS definition isn't necessary, because rules_scala will do the right thing without it. But if you do use SCALA_VERSIONS, it must contain SCALA_VERSION. Check out the relevant stanza from scala_config.bzl.

There's a similar, but slightly more detailed example in the MODULE.bazel file from my bzlmod working branch. The key difference there is the dev_dependency = True argument to use_extension. That's there because that configuration is only for developing rules_scala, not for its consumers.

[zcking]

@mbland Totally get it! My comment was mostly intended to show support for this issue and vested interest outside of the normal contributors. This work is really important if Scala is to join many other languages already up-to-speed in the Bazel registry.

Also, although I'm not familiar with development for bazel rules such as this, I'd be happy to help contribute in my spare time if any additional help is needed!

[mbland]

Another quick update...

@zcking I appreciate the offer for help. I feel like the actual code changes are essentially complete, modulo adjustments based on review feedback. Feel free to look at the outstanding and upcoming PRs and offer any feedback or questions if you have any.

@simuons provided some feedback on #1633 that prompted me to make some adjustments and to ask for confirmation on whether to make certain other changes. This one will establish the direction for pulling other changes from my Bzlmod working branch. Though it will remain compatible with WORKSPACE, there will be small yet breaking changes from the existing WORKSPACE API, so it's worth taking the time to get it right.

I've reached some conclusions with regard to my Protobuf compatibility and upgradeability side quest, which I've written up in #1647. I found that rules_scala can either support up to Protobuf v25.5 when building with both Bazel 6 and 7 (with C++ compiler flags set for Bazel 6), or can leap to supporting only Protobuf v28.2 and above. My suggestion is to support v25.5, since the current v21.7 seems too old, but I'd fear switching straight to v28.2 might break too many users right now.

I've opened some new PRs to make a few improvements to the build and test scripts along the way:

• Refactor scripts/create_repository.py, improve efficiency and correctness, and bump Scalatest, protobuf-java, kind-projector #1642
• Make every .bazelrc import the top level .bazelrc #1644
• Clean test_{runner,scalafmt_helper}, add diagnostic env vars, and improve test_cross_build performance #1646

The first and last of these, in particular, turbocharged my Protobuf investigation:

• The create_repository.py script is now super fast, does more to ensure the entries in the generated third_party/repository/scala_*.bzl files are accurate, and updates more core artifacts (including ScalaPB in my bzlmod-update-protocbridge-and-grpc and bzlmod-update-abseil-cpp-and-protobuf working branches).
• The new RULES_SCALA_TEST_ONLY and RULES_SCALA_TEST_VERBOSE env vars made it easier to iterate on specific test cases or files from test_all.sh, test_version.sh, etc., and to see what was happening. (The default is to only emit output on failure, after the command finishes, which proves especially problematic if a test hangs.)

I also figured out how to put a nail in the coffin of the generators-hanging-on-Protobuf-upgrade issue by wrapping ScalaPbCodeGenerator to catch and report previously uncaught exceptions.

At this point, it's just a matter of taking the time to land things properly. No need to rush, and now that I've got all my tools and investigations and proofs of concept working, I plan to take it easy for a while. 🙂

[mbland]

OK, here's my latest weekly update. 🙂 The executive summary is that we're in the home stretch here.

#1633 is super close to going in. And now that I think about it, I think there aren't any WORKSPACE API-breaking changes after all. All the old macros should continue to work with existing builds with no changes (though scala_toolchains is nicer and can shrink existing WORKSPACE files substantially). So technically, the only "breaking" change so far (or bugfix, depending how you look at it) comes from removing external/$REPO)_NAME path prefixes from embedded resources, from #1621.

Speaking of #1621, I've superseded the apparent_repo_name utility from that pull request in the new #1650. Not critical, but it's the right thing to do; I've also closed bazelbuild/bazel-skylib#548 as a result. And an update as of this morning: The Bazel maintainers may be considering a new repository_ctx field to render this workaround unnecessary (eventually).

Integrating the changes from #1648 broke my bzlmod-rebuilding working branch, because instantiating scala_proto toolchain repos collided with instantiating ScalaPB repos for scalafmt and Guava repos for twitter_scrooge under Bzlmod. The WORKSPACE implementation doesn't care, but it's an error to instantiate the same repo multiple times from a module extension:

$ bazel build //src/...

ERROR: .../scala/scala_maven_import_external.bzl:299:24:
  Traceback (most recent call last):
    File ".../scala/extensions/deps.bzl",
      line 140, column 21, in _scala_deps_impl
        scala_toolchains(
    File ".../scala/private/macros/toolchains.bzl",
      line 140, column 17, in scala_toolchains
        _scrooge(
    File ".../twitter_scrooge/twitter_scrooge.bzl",
      line 96, column 17, in twitter_scrooge
        repositories(
    File ".../third_party/repositories/repositories.bzl",
      line 113, column 37, in repositories
        _scala_maven_import_external(
    File ".../scala/scala_maven_import_external.bzl",
      line 263, column 30, in scala_maven_import_external
        jvm_maven_import_external(
    File ".../scala/scala_maven_import_external.bzl",
      line 299, column 24, in jvm_maven_import_external
        jvm_import_external(jar_urls = jar_urls, srcjar_urls = srcjar_urls, coordinates = artifact, **kwargs)

Error in repository_rule: A repo named
  io_bazel_rules_scala_guava_2_13_15
  is already generated by this module extension at
  .../scala/scala_maven_import_external.bzl:299:24

ERROR: Analysis of target
  '//src/java/io/bazel/rulesscala/worker:worker_test'
  failed; build aborted:
  error evaluating module extension scala_deps in
  //scala/extensions:deps.bzl

This led me to develop a schema whereby the toolchains declare their Maven artifact dependencies in a separate macro from the one that calls repositories to instantiate them. (The Scalafmt toolchain had defined a similar macro before, to accommodate different artifact sets for different Scala versions, which I've since updated.) This allows the new scala_toolchains macro from #1633 to collect all the artifact IDs, de-dupe them, and call repositories itself. You can see the final result in scala/private/macros/toolchains.bzl from my bzlmod working branch.

I've prepared commits for the testing toolchains and the Scalafmt toolchain already, to land in that order after #1633. I've started one for the scala_proto toolchain, but want to wait for #1648 to land before going further with it, since that PR introduces scala_proto_artifact_ids, which I'd used to accommodate differences between Scala 2.11 and other versions.

After that, there'll be:

• either one or two pull requests to add the jmh and twitter_scrooge toolchains; I do have twitter_scrooge building under Bzlmod already, with all native.bind calls removed and all tests passing
• a pull request to prepare the dt_patches repos for Bzlmodification. as well as remove duplication
• maybe one pull request to remove all remaining uses of @io_bazel_rules_scala, so that Bzlmod users can usebazel_dep(name = "rules_scala", version = "7.0.0") without a repo_name = "io_bazel_rules_scala" parameter
• at least one more pull request to drop in MODULE.bazel files, module extensions, and remove --noenable_bzlmod from .bazelrc; this could be more than one, depending on the maintainers' appetite to migrate all internal repos at once, or one at a time, or in batches
• either in the above pull request or in a separate one, turn the Bazel last green head build back on using Bzlmod to close Bazel green build CI job now fails persistently due to rules_java versioning #1625

We could also bump the default .bazelversion to 7.4.1 (or whatever the latest is by that point) and/or bump Protobuf to v25.5, per #1647, but that's not strictly critical. (It would technically break Bazel 6 users, because they'd have to add C++ compiler flags to their .bazelrc to build Protobuf v22 and later.)

At some point I'll look into adding the Publish to the Bazel Central Registry tool, probably after the official 7.0.0 release, unless the maintainers would prefer to do it themselves. After that, and when https://registry.bazel.build/modules/rules_scala goes live, I think we could close this issue!

[mbland]

Weekly update!

#1633 and #1650 are approved and hopefully landing soon. Then I'll fire up the pull request factory again.

But in related news, it's all Protobuf + ScalaPB, all the time, with Bazel 8 and rules_java 8 starting to join in on the fun. #1647 has all the links to all the details, but here's the high level recap.

Upstream ScalaPB and protoc-bridge changes to avoid rules_scala ProtoScalaPBRule build hangs

I filed scalapb/ScalaPB#1771 to volunteer to contribute scalapb.ScalaPbCodeGenerator changes upstream to avoid build hangs due to Protobuf + ScalaPB incompatibilities. Right after that, I noticed the latest protoc-bridge implementation of PluginFrontend.runWithInputStream(). It apparently landed as part of scalapb/protoc-bridge#367, without being specifically called out in the pull request description or discussion. It's not in the latest protoc-bridge 0.9.7 release, however.

Ideally a new protoc-bridge release will come out soon, which might obviate the need to contribute to ScalaPB or maintain the scalapb.ScalaPbCodeGenerator changes from #1648 indefinitely. But I have no idea if or when that might happen.

Bazel 8 and rules_java 8 compatibility requires breaking WORKSPACE builds

Just this morning, I noticed #1652, and experimented with local changes to build using Bazel 8.0.0rc4 on top of my bzlmod working branch. I found (copying from my summarization on the related bazelbuild/bazel#24235) that most of the Bazel 8 and rules_java 8 incompatibilities can be easily addressed once Bzlmodification lands. What I think is the only remaining one may be resolved by a protobuf-java:4.29.0 release (without -RC2). (Granted, I didn't run the full test suite, but bazel build //src/... //test/... //third_party/... //scala_proto/... is a decent smoke test.)

The tradeoffs are that users will be forced to upgrade to Protobuf v28.3 under Bazel 6 and 7 (thanks to ScalaPB 1.0.0-alpha.1), and Protobuf v29 under Bazel 8. , and the load("@rules_java") statements required by Bazel 8 to define JavaInfo and java_common.JavaToolchainInfo will break WORKSPACE users for good. Then again, that may be all the more reason to suggest folks migrate to Bzlmod sooner than later.

Versioning for Bzlmod and Bazel 8 compatibility

I'm thinking, if the maintainers are OK with it, it might be worth including Bzlmodification in the next major release (7.x), and then building up to Bazel 8 compatibility in another major release (8.x). The Bazel 8 compatibility release could happen very soon after, since it won't require that many changes. rules_scala 7.x would give existing WORKSPACE users a chance to migrate to Bzlmod first, using either Bazel 6 or 7. Then rules_scala 8.x would enable them to build using Bazel 8. , but only under Bzlmod

Or maybe one could argue for Bzlmodification being released as rules_scala 6.7.0, since I think the only confirmed breaking change is possibly the "bugfix" from removing external/$REPO_NAME path prefixes from embedded resources in 1621. Or, if we bump Protobuf up to v25.5 (or v24.4, since that's the highest compatible version of the protobuf module in the Bazel Central Registry), we'd have to tell Bazel 6 users to add some compiler flags. But then Bazel 8 compatibility would be a truly breaking change, requiring a major 7.0.0 release.

I'm particularly interested in what @simuons and @liucijus think of sacrificing WORKSPACE users for implementing Bazel 8 compatibility, and when. Curious what others think of the possibility as well.

Update from bazelbuld/rules_scala#1652: I spoke too soon: I can get a WORKSPACE build to use rules_java 8.5.1 and the other updated repo versions, and get to the point where it reaches the Detected mismatched Protobuf Gencode/Runtime version suffixes error.

So it seems we could bump rules_scala to Bazel 8 and rules_java 8 without abandoning WORKSPACE, but we will abandon Bazel 6 and 7 at that point.

One more update: I've created the bazel-8-compatibility working branch in my rules_scala fork with the commit message for mbland@ebe714d describing the current build breakages, which are the same under WORKSPACE and Bzlmod.

Note that this branch/commit is based on my bzlmod working branch, not the current upstream master branch.

[simuons]

Hi, @mbland, If I understood you correctly I'm leaning towards your first proposal:

Bzlmodification in the next major release (7.x), and then building up to Bazel 8 compatibility in another major release (8.x). The Bazel 8 compatibility release could happen very soon after, since it won't require that many changes. rules_scala 7.x would give existing WORKSPACE users a chance to migrate to Bzlmod first, using either Bazel 6 or 7. Then rules_scala 8.x would enable them to build using Bazel 8.