Skip to content

Home

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 2

In the previous post, we reviewed guidelines for maintaining compatibility with both Bzlmod and legacy WORKSPACE builds, and older and newer dependency versions. I promised that in this post and the next, we'd discuss testing approaches to help ensure that this remains the case.

However, a discussion in the Bazel Slack workspace has revealed a Bzlmod and legacy WORKSPACE compatibilty issue I'd missed in the previous post. So in this post, I'll discuss what to do with the class of legacy WORKSPACE configuration macros that use Label with computed repository names.

As we'll see, this one issue alone ended up meriting a substantial post in itself. We'll cover adding dependency attributes to repository rules, generating .bzl files to resolve Labels, chaining together module extensions, and using macros in generated BUILD files. The former two options are relatively straightforward, but we cover the latter two options in case your use case requires them.

Such legacy WORKSPACE macros commonly seem to pertain to toolchain configuration, selecting repositories to instantiate based on user defined parameters. So we'll use a small example project to illustrate these solutions as they apply specifically to toolchain configuration.

In the next post, I promise to get into the tasty testing stuff, in what promises to be the third of a four part trilogy.

Boston: Around the World with Bazel in Watercolors

This article is part of the series "Around the World with Bazel in Watercolors".

Boston is my second favorite city, after New York, of course! More on why below. It was a 1.5 day trip to meet the Boston Bazel community on the way to NYC from another San Francisco visit. Given the short trip, I only got a chance to do a tiny watercolor - see the cultural notes. However, I’ve gone back to Boston during my family vacation in Cape Cod, so I have much more to share in the form of my daily watercolor inspiration from the various day trips we’ve done on the Cape!

Boston Watercolors

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 1

As we're well aware by now, Bzlmod is the new hotness, and WORKSPACE is old and busted and going away in Bazel 9. However, Bazel 8 still supports WORKSPACE, and thus legacy WORKSPACE usage won't completely disappear for some years yet. Despite the Bazel community's efforts to help facilitate Bzlmod migrations (including this blog series), some projects may remain unable to migrate sooner than later.

What's more, publishing your repository for use by other projects raises the challenge of supporting a range of older and newer versions of its dependencies. Your repository should work with the newest versions of Bazel, rules_java, protobuf, and other dependencies in order to stay current. However, not every project that could benefit from the latest version of your repository will want to upgrade these other dependencies right away.

This post describes how to design a repository to remain compatible with both WORKSPACE and Bzlmod, and with newer and older dependency versions. Just as importantly, in the next two posts, we'll discuss testing approaches to help ensure that this remains the case.

Build Meetup in London – Recap

In May, we co-hosted the London Build Meetup with Tweag by Modus Create and Jane Street. Build system insights, stories about first-hand build challenges, and great conversations packed the afternoon and evening. The lineup covered everything from large-scale migration battles to new research. If you missed it, here’s what you need to know.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Toolchainization

Part of the promise of Bazel modules is that they are largely self-initializing in an order-independent way. Rule sets, in particular, no longer need to burden users with importing and invoking macros to instantiate repositories and toolchains in a specific order. This burden now shifts to rule set maintainers, but the existing implementation may not provide this ease of use without modification.

This post describes the introduction of a new "toolchainized" API for rules_scala v7.0.0 that better encapsulates toolchain configurations and dependencies. We'll see how this new design enables optimal Bzlmod compatibility, while simultaneously shrinking the legacy WORKSPACE API surface without losing functionality. We'll also see how the Bzlmod and legacy WORKSPACE APIs provide similar interfaces while sharing the same underlying implementation, facilitating Bzlmod migrations.

  • in engflow
  • 3 min read

Rooted in Partnership: Celebrating Our Customers with the EngFlow Customer Forest

As a thank you for our customers’ incredible support, we launched the Customer Forest Initiative. Throughout the 2024 holiday season, we planted trees on behalf of our customers, as an expression of our gratitude. The Customer Forest represents shared progress and growing stronger together.

We wanted a gift that truly reflected the value of our partnerships and the impact we can achieve together. Planting trees was the perfect choice, symbolizing growth, connection, and our shared commitment to a better future with our customers.

Build Meetup in Munich – Recap

Another successful build meetup done! Our April meetup was co-hosted by JetBrains. The night was all about swapping stories, learning something new, and enjoying some good food and drinks. If you missed out, read the recap below and check out meetup.build for the next one!

Build Meetup April 2025

  • in engflow
  • 5 min read

2025 EngFlow Global Summit - Five Takeaways

Team celebrating 5 years of EngFlow and 10 years of Bazel in Salzburg

Summit kickoff dinner where we celebrated 10 years of Bazel and 5 years of EngFlow.

Once again, the EngFlow team gathered for our annual Global Summit—convening this time in the beautiful city of Salzburg, Austria. This year’s summit was a milestone event—bringing the team together from around the world to celebrate five years of EngFlow. We also toasted to ten years of Bazel (thanks to our CTO Ulf Adams, our engineers, and the many others who have contributed so much to the community over the last decade). In keeping with the anniversary theme, here are five takeaways from the summit to give you a glimpse into our time together:

Migrating to Bazel Modules (a.k.a. Bzlmod) - Repo Names, Again…

The apparent and canonical repository name schema under Bzlmod is the gift that keeps on giving. Much of what it has to give is quite good—once you learn how to really hold it right. Which is to say, to avoid holding canonical repo names at all. That's what the three previous "Repo Names..." posts in this series were all about.

Those previous posts, however, pertained to using BUILD rules, or when accessing runfiles. In those situations, solutions exist to avoid handling canonical repo names directly as a consumer.

If you maintain a Bazel rule set, or need to fix a rule set upon which your project depends, this is the post for you. We'll see how improper repo name usages sneak into rule implementations, and how to shoo them out. Examples include removing canonical repo names from embedded resource paths, filtering lists of target labels, and generating default repository target names. We also discuss removing internal references to your project's own apparent repository name to avoid minor yet preventable issues.