Bazel source folder layout and go tools.

[linuxerwang]

Hi, rules_go maintainers

I've used bazel + rules_go in my company for about 8 months (since from it was in tools/build_rules). In general I am very satisfied with using bazel to build our highly collaborating modules, but I am always bothered by issues preventing other go tools to work with the folder layout, because of the way we organize code differently from standard Go:

app2/
app3/
...
3rdparty/
    |- vendor/
           |- github.com/
                  |- ...
BUILD`
WORKSPACE

I like this folder layout since it's very clean and easy to maintain, especially when Go files are mixed with other files like Java/Python. Bazel builds all of these apps nicely. The problem is that all go tools such as gocode, godoc, guru and IDEs like liteide, expect a GOPATH and src, pkg, bin folders under it, thus they ALL break with bazel's folder layout. The top level BUILD file adds a custom prefix which doesn't match the real folder.

I submitted a commit to let gocode to support bazel folder layout: https://github.com/nsf/gocode/commit/725b543fef1c612e2885f9a3ad83c5fca52fd97a. It allows gocode to autocomplete AFTER the target has been built successfully (because it reads the .a file), so it's not perfect.

I also used some workarounds like create a GOPATH and symlinks to form a standard layout. With the workarounds some Go tools work a little better (Intellij works the best) but far from perfect.

Can the rules_go maintainers please give us suggestions to solve this problem?

Thanks!

[mightyguava]

We have a similar problem.

I'm trying to set up our multi-language monorepo to use Go, but it seems I'll have to do some crazy symlinking to get this to work due to the way the rules rely on go_prefix().

Our repo layout looks roughly like this.

/
  3rdparty/
    go/
       bitbucket.org/...
       github.com/...
       golang.org/...
  src/
    go/
      com/compass.com/...
    java/
      com/...

Our go prefix is already part of the directory tree, and we want to support vendored code within /3rdparty.

This layout has worked really well for us, and works quite well with Bazel's java support. Do you have suggestions on how to use the Go rules for our repo?

[pmbethe09]

Both good examples/questions -- not something I had thought of. Suggestions are welcome.

[linuxerwang]

Today an interesting idea bumped into my head for solving this issue. I'll try on it this weekend and hopefully we'll get a perfect solution (although for Linux only). Stay tuned.

[linuxerwang]

Here it is: https://github.com/linuxerwang/gobazel

The idea is to simulate a GOPATH directory tree with FUSE. It's not perfect, but works for all Go tools and IDEs. Let me know your thoughts.

[jmhodges]

As an additional reason for some rule_go GOPATH help, this would probably help my attempts to get mockgen and similar tools working against go_proto_library deps, etc.

[jmhodges]

Yeah, if you try exposing the .pb.go in rules_go and using those directly with mockgen -source isn't working. See https://github.com/golang/mock/issues/11#issuecomment-294380653

I'm really stuck here without a $GOPATH. I'm not sure how to get past this impasse.

[jayconrod]

Closing old issues.

Bazel and rules_go don't impose any specific requirements on repository layout, now that go_prefix is gone. In general, life will be easiest for repositories that follow the GOPATH layout because many tools make assumptions about GOPATH structure.

We're working on golang.org/x/tools/go/packages, which will let tools handle Go code independently from workspace structure. This is motivated by the upcoming Go modules, which also don't follow GOPATH. There will be an extension point for Bazel and other build systems.