bazel-contrib / bazel-contrib/rules_go

How to do partial migrations to bzlmod?

Open
#4,433 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1.5k
Forks
760
Avg merge
1d 11h
Merged PRs (30d)
12

Description

First off: thanks so much for your work on this. I have a question for y'all.

How does one set up your WORKSPACE so you can move your `go_repository` calls to MODULE.bazel slowly over time, instead of all at once? Or is that even a thing y'all are supporting?

Adding both the `bazel_dep`s for rules_go, and gazelle in MODULE.bazel (while keeping their previous names with `name` as documented) as well as doing the usual `go_register_toolchains` / `go_rules_dependencies` / `gazelle_dependencies` calls in WORKSPACE seems to load a different set of deps and gazelle tooling in subtle ways. I had started to write a bug about one difference breaking builds, but realized I wasn't sure I was doing the correct set up in the first place.

The directions in the [rules_go bzlmod docs](https://github.com/bazel-contrib/rules_go/blob/6d90ede1ac59fea5417886329a9cae5eebd1a1b1/docs/go/core/bzlmod.md) say we can add `rules_go` and `gazelle` to our MODULE.bazel and then "refer" to them in WORKSPACE dependencies. But it doesn't say anything about what calls to make on the WORKSPACE side to ensure the `go_repository` and gazelle infra works correctly.

For clarity: The "move all of the Go deps in WORKSPACE to Bzlmod in one big bang" hasn't been working well, so I'm investigating how to break it up.

Problems with the big bang we've run into include: The migration tools breaking on edge cases on like rules_webtesting requiring both a version bump and referring to its multiple modules at once (there's now a Go-specific module you're supposed to depend on, & the migration tools error out before finishing). Some of the Go module deps in our build require surgery to move them from being `git_repository` calls (which isn't yet supported by the Go bzlmod code) because they're cgo modules that need hacks in place to link to C dylibs from other bazel targets.

But we're happy all this stuff works at all! Thanks, again

Contributor guide

Open the contributing guide

Research direction

Read the rules_go bzlmod documentation linked in the issue, then compare the MODULE.bazel and WORKSPACE setup described there with the migration tools and the reported rules_webtesting and cgo cases. Document whether partial migration is supported, which WORKSPACE calls remain necessary, and what a successful mixed setup looks like.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.