search

bazelbuild / rules_go

Go rules for Bazel
Apache License 2.0
1.37k stars 650 forks source link

BzlMod external Dependency instructions are not working #4104

Open bdleitner opened 1 week ago

bdleitner commented 1 week ago

What version of rules_go are you using?

0.50.1

What version of gazelle are you using?

0.38.0

What version of Bazel are you using?

7.3.1

Does this issue reproduce with the latest releases of all the above?

Yes.

What operating system and processor architecture are you using?

Windows 10 x64

Any other potentially useful information about your toolchain?

No

What did you do?

I tried to use the rules_go bzlmod docs to set up a very simple dependency between local modules and then later with an external dependency (com_github_golang_protobuf) just to test that I knew what I was doing, but even those minimal examples failed.

I created a repo for my minimal examples at https://github.com/bdleitner/golang_bzlmod_demo

What did you expect to see?

bazel run @rules_go/go -- mod tidy -v should update the go.mod file and not show errors, and should update the use_repo section of MODULE.bazel as well.

Once the use_repo section is manually updated, bazel build should succeed.

What did you see instead?

bazel run @rules_go/go -- mod tidy -v reports errors some errors and does not update the go.mod file or the use_repo section of MODULE.bazel. bazel mod tidy removes entries from use_repo that I need.

Once the use_repo section is manually updated, bazel build should succeed - this seems to work for the github.com/golang/protobuf dependency if I fix everything manually, but the tooling at best doesn't help and at worst tries to remove needed entries. Nothing seems to work for "local" external dependencies.

fmeum commented 1 week ago

Thanks for the very detailed description of the challenges you faced.

We don't currently support absolute paths in replace directives and I'm not sure we will any time soon: Bazel is very much designed to not reference absolute paths in a build.

You might want to look into go.work support if you really want a multi-module project, but I would heavily recommend against that unless you already have such a build. With Bazel, there isn't much of a point to this as you can create arbitrary package structures and enforce relations between them via visibility. A monorepo is definitely closer to the happy path with Bazel.

fmeum commented 1 week ago

Regarding protobuf, you are running into an issue ultimately fixed by this commit https://github.com/bazelbuild/rules_go/commit/2f062f88541f73d7cb4b5290b76b12f3bc2123ee a few hours ago. go get doesn't work well with non-go build build systems as it never marks dependencies as direct. Unfortunately upstream has decided to leave this as is, but with the commit above, at least @rules_go//go should give you a better experience.

You could also try to run go mod tidy with the -e flag to continue through errors - definitely recommended if you have generated code.

We should definitely improve the docs, so if you identify anything that's missing, it would be highly appreciated if you could send a PR.

bdleitner commented 1 day ago

We don't currently support absolute paths in replace directives and I'm not sure we will any time soon: Bazel is very much designed to not reference absolute paths in a build.

I'm working on consolidating into a monorepo, but for curiosity: the issues with trying to get "local" remote repos to work also manifest in the same way if I used relative paths (e.g. "../otherworkspace") in the go.mod file. Would that fall under the same "not supported" issue?

fmeum commented 1 day ago

Relative paths should work since https://github.com/bazelbuild/bazel-gazelle/pull/1776. But I haven't tried this myself yet, so if you find something that needs to be fixed, please let me know.