Minimum working example for go_path?

[Michael Leonard]

Hi

I'm evaluating using Bazel for a new greenfield go monorepo and I'm hoping to get a bit of help with choosing the best directory structure upfront and getting IDE integration to work as best as is currently possible.

From reading github issues and blogposts I'm worried about IDE integration and the issue that various go tools expect the standard GOPATH layout.

Is there a 'best practice' directory structure for a go monorepo? One that gives IDE/go tooling integration the best chance of working well now and in the future? (ie I'd like to be able to cmd+click to 'go to source' inside of dependencies and generated go code)

Is the 'go_path()' rule the right way to achieve this at the moment? Could someone point me to a working example of this rule? 

(Currently I have a hello-world go http server building fine in Bazel, with an external dependency on the gorilla-mux library specified in the WORKSPACE file as an external dependency. How is the go_path() rule supposed to work exactly? When I 'bazel build' the go_path() rule I'm unclear from the documentation where it is outputting the symlinked files?)

Thanks in advance for any help! 

Will do my best to contribute to the docs and provide feedback as a new user as I get things working over the next few weeks

Mike

[Jay Conrod]

At the moment, the best practice for this is to have a directory that can be added to your GOPATH. So basically, have a src directory in your repository root, or somewhere deeper, but all the Go code would be under src. Until tools are aware of Bazel, the best thing to do is to show them something that fits in GOPATH. This works in most cases, but generated Go code won't be visible, since Bazel stores that separately in the build cache.

If you're using Gazelle, you can make sure it gets the import paths right by adding this comment to src/BUILD.bazel:

# gazelle:prefix

This sets the empty prefix at src. Libraries defined below that will have their importpath set to the relative path from src/. So for example, src/github.com/foo/bar will have the importpath github.com/foo/bar.

You originally asked about go_path. This may be useful if you have a tool which you want to invoke through Bazel that only understands GOPATH. I don't have a complete example for you at the moment, but you might find the go_path test package useful. go_path won't be useful for interactive tools such as godef, goimports, gocode, gorename, or guru.

Long term, the Go Tools team is working on an abstraction layer between tools and build systems. This is driven by the need to support vgo, which doesn't require GOPATH. Bazel and other Go build systems will also benefit from this. This is our highest priority project right now, but getting the API right and supporting current tools and build systems is a lot of work, so it will take some time. We don't have anything public yet, but I expect we will soon.

--
You received this message because you are subscribed to the Google Groups "bazel-go-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-go-discu...@googlegroups.com.
To post to this group, send email to bazel-go...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-go-discuss/cab3aafb-dad1-42b4-b70d-55ad0781dba5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.