rules_go: go_path not working correctly for vendored sources
We have a mono repo where the go sources have the following directory structure:
- go
\- src
\- mypkg
|- vendor
go_path produces the following directory structure:
- src
\- mypkg
|- go
\- src
\- vendor
which prevents standard tools from finding the vendored packages.
I think this is a result of go_path using the importmap attribute of the vendored packages. We used gazelle to auto-generate the go targets, which have the importmap attributes set automatically. Not sure what’s the right thing to do here.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 19 (12 by maintainers)
Commits related to this issue
- Set importmap in vendor to prefix concatenated with relative path Previously, when entering a vendor directory, the importmap prefix was set to the workspace name (read from WORKSPACE) concatenated w... — committed to jayconrod/bazel-gazelle by deleted user 6 years ago
- Set importmap in vendor to prefix concatenated with relative path (#207) Previously, when entering a vendor directory, the importmap prefix was set to the workspace name (read from WORKSPACE) concat... — committed to bazelbuild/bazel-gazelle by jayconrod 6 years ago
@zanes2016 A single Bazel build would be possible, but you’d need to edit the build files to avoid the conflict. Gazelle won’t be able to do it for you. In this case, you could depend on
@com_github_hashicorp_consul//vendor/github.com/hashicorp/serf/coordinate:go_default_librarydirectly.In general, rules_go is the mechanism, and Gazelle is the policy. Gazelle will generate rules that do the same thing as
go build. In this case,go buildreports an error, and the rules generated by Gazelle give you the same error. But if you’re willing to hand-write build files, you more flexibility, but it’s a lot more work.