Add layout for projects using the gb build tool for Go

[ches]

Hi,

Thanks for making direnv, it's quite handy!

I've been using the gb build tool for Go on private application projects, and I keep adding this setup to my .envrcs. It might be slightly controversial but since it's a small thing I thought I'd submit and see if there is interest.

The reason it might be slightly controversial is that gb doesn't actually use GOPATH at all—it's included here because setting it facilitates use of common Go tools and their integration in editors. Without direnv, teammates got tool integration working with vim-go, GoSublime, etc. by setting GOPATH (and possibly PATH) in project-local config like localvimrc or Sublime project-specific settings. After standardizing on using direnv, everyone simply starts their editor from their shell and things just work without extra editor-specific setup.

Unlike the layout_go already in direnv, this does not extend a global shared GOPATH with the local project directory, gb's ideology is that the project's local src and vendor directories comprise everything needed to build the project, so tools shouldn't be analyzing any source or library archives outside of the project.

$PWD/vendor/bin is added to PATH for the sake of build dependencies that may install executable tools, for example the Ginkgo BDD testing framework includes a ginkgo test runner executable.

To be clear, intended usage is that you already have the typical Go development setup of a globally shared GOPATH configured in your shell environment by default, and $GOPATH/bin added to your path. This way you don't need to install copies of gocode, godoc, etc. in vendor of every project, the global ones installed with go get outside of a gb project will still be on your path and work when using layout gb. It should work fine if you do go get some of the tools while using the layout, it just might be slightly confusing that they get installed to $PWD/vendor, which is another caveat to consider.

[ches]

If this isn't acceptable as a patch, I'll add a tip for the tool usage with gb to https://github.com/direnv/direnv/wiki/golang

[zimbatm]

Hi @ches, thanks ! I am sorry for the delay as I got caught-up in sickness.

I am trying to include only non-controversial tools in the stdlib so I don't know about gb. It sure looks useful and I think is going in the right direction for go. Ideally I would prefer to have one canonical layout_go once golang has converged on the one true tool. I also don't mind adding $PWD/vendor/bin to the go layout. This is just my opinion right now but feel free to insist if you think that I am wrong.

In the mean-time, do you know about the ~/.direnvrc file ? The content is sourced before loading any .envrc file. I use it to develop my own stdlib before importing it upstream if it makes sense. I know it's not super convenient but you could share the layout_gb function that way.

tk,
z

[ches]

No worries, can totally understand your position for this case and ~/.direnvrc would be just fine for me as a personal solution, thanks for your response. I figured it might not be acceptable at this point but would still be worth making the proposal so others might find the PR by search, and could readily use it in their ~/.direnvrc as well.

The Go 1.5 "vendor experiment" is actually becoming more and more like gb's exact approach as it gets refined, so this might become relevant again when the official tools finally bless a supported workflow consensus.

[ches]

Added the wiki FYI: https://github.com/direnv/direnv/wiki/golang#using-the-gb-build-tool

[zimbatm]

Thanks, you're the best !