Add `go` and `go-env` goals.
Review Request #3060 - Created Oct. 30, 2015 and submitted
|kwlzn, mateor, molsen, stuhood|
These goals support running arbitrary go commands and arbitrary third-party commands that respect the $GOROOT and $GOPATH. In particular, 2 usecases are immediately enabled: 1. Certain enhanced Go editor environments now work with pants Go source trees including their 3rdparty deps, two of which this change was tested with: The GoSublime plugin for the Sublime Text editor and the go-vim plugin for the vim editor. 2. Certain go tooling without direct pants support can be used. In particular `./pants go [targets] -- vet` now runs `go vet` for the given targets providing linting for common non-compile-time errors. Tests are added for these tasks. contrib/go/src/python/pants/contrib/go/register.py | 3 ++ contrib/go/src/python/pants/contrib/go/tasks/BUILD | 13 +++++++ contrib/go/src/python/pants/contrib/go/tasks/go_go.py | 85 +++++++++++++++++++++++++++++++++++++++++++++ contrib/go/tests/python/pants_test/contrib/go/tasks/BUILD | 12 +++++++ contrib/go/tests/python/pants_test/contrib/go/tasks/test_go_go.py | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 207 insertions(+)
Manually tested with go-vim and sublime via:./pants go-env contrib/go/examples:: -- subl ./pants go-env contrib/go/examples:: -- vim
In both cases, the plugins could both browse to 3rdparty code, stdlib code
and symbol completion for these worked as well. In the case of the stdlib
code, browsing was against the
distribution as would be hoped.
Additionally successfully used the following to vet examples:$ ./pants go contrib/go/examples/:: -- vet INFO] Detected git repository at /home/jsirois/dev/3rdparty/jsirois-pants4 on branch jsirois/go/go .pants.d/go/go/contrib.go.examples.3rdparty.go.github.com.kr.pretty.pretty/src/github.com/kr/pretty/formatter_test.go:46: possible misuse of unsafe.Pointer exit status 1 .pants.d/go/go/contrib.go.examples.3rdparty.go.github.com.gorilla.mux.mux/src/github.com/gorilla/mux/mux_test.go:1080: arg len(ancestors) for printf verb %s of wrong type: int exit status 1 .pants.d/go/go/contrib.go.examples.3rdparty.go.gopkg.in.check.v1.check.v1/src/gopkg.in/check.v1/printer.go:89: go/printer.CommentedNode composite literal uses unkeyed fields .pants.d/go/go/contrib.go.examples.3rdparty.go.gopkg.in.check.v1.check.v1/src/gopkg.in/check.v1/printer.go:162: go/ast.ExprStmt composite literal uses unkeyed fields .pants.d/go/go/contrib.go.examples.3rdparty.go.gopkg.in.check.v1.check.v1/src/gopkg.in/check.v1/printer.go:162: go/ast.Ellipsis composite literal uses unkeyed fields .pants.d/go/go/contrib.go.examples.3rdparty.go.gopkg.in.check.v1.check.v1/src/gopkg.in/check.v1/printer.go:167: go/ast.BlockStmt composite literal uses unkeyed fields exit status 1 ...
Just running against
contrib/go/examples/src::produced no errors.
CI went green here:
so FWIW, the code looks fine to me.
I only have one suggestion, and this may expose my ignorance, but it seems to me that surfacing this information would be of primary importance to users. Is this going to show up in the documentation somewhere? Just even the examples listed in the summary section would be enormously helpful for people trying to figure out how to set up their editor environment for interop with pants. I wish I had a good suggestion for how to achieve this, but I'm not sure how the docs are organized for the project.
Anyway, thank you for adding this. I had some concern about pants/go adoption without this feature, because one thing that's so attractive about go is the tooling. This feature goes a long way to help interop with the larger Go ecosystem.