Skip to content

2025

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.

Not all builds are made equal: Using priorities to expedite remote execution of the builds and tests that matter most

TL;DR

Imagine reading this post on your internal Slack:

⚠ Please hold off on pushing your PRs for a bit until the patch release is fully cut. We don't have enough capacity to handle all the load and the patch is blocked because of that.

Ouch.

But let's be real: not all builds are made equal - some builds are more urgent than others. Like here, when creating a patch release, and wanting to expedite the builds required for it over others.

Yet there's got to be a better solution than asking everyone else to not push changes.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Fixing and Patching Breakages

In the previous Bzlmod post, we covered writing your own Bazel module extensions to adapt your own setup code for dependencies that aren't Bzlmod compatible. However, there are other Bzlmod incompatibilities and related breakages that module extensions alone can't fix, such as forbidden API usage or Windows path length errors.

This post shows you how to patch your dependencies and covers several situations where patching is the only solution. We'll describe how to create and apply patches for your dependencies, if you can't wait for upstream fixes (or contribute them yourself).

What I learned in Colombia

EngFlow has multiple entities around the world, one of which is in Colombia. This year we’ve chosen Colombia as the site for our 2025 Leadership Summit, and I added a few days and weekends to explore the country with our team members, see how they live and meet their families. It’s been an incredible experience visiting Medellin, El Retiro, Itagui, Cali and Bogota, and I’ve captured a few learnings from this trip in a blog.

Colombia team photos

Migrating to Bazel Modules (a.k.a. Bzlmod) - Module Extensions

So far, we've covered relatively easy Bzlmod fixes, how to hold runfiles and pkg_tar correctly, and how to access canonical repo names when absolutely necessary. Now we'll discuss replacing WORKSPACE statements with your own module extensions. You can use them to wrap your project's setup macros, and to adapt external repositories that aren't Bzlmod compatible to work with your Bzlmodified project.