Feedback: should be able to use go tool on a project's dependencies

[myitcv]

This issue picks up a conversation with @sdboyer and @peterbourgon on Slack. It’s essentially a broader version of #348 amongst others.

Best illustrated by a commented, runnable example:

# setup a fresh project

cd `mktemp -d`
export GOPATH=$PWD
mkdir -p src/github.com/myitcv/blah && cd $_
dep init

# write some code that depends on github.com/pkg/errors, for example

cat <<-EOD > main.go
package main

import "fmt"
import _ "github.com/pkg/errors"

func main() {
		 fmt.Println("Hello world")
}
EOD

# now dep ensure to get the package dependency

dep ensure github.com/pkg/errors@ff09b135c25aae272398c51a07235b90a75aa4f0

# check the build passes

go build || (echo "Build failed cannot continue..." && return)

# we cannot list information about package dependencies using their import path

echo "\$ go list -json github.com/pkg/errors"
go list -json github.com/pkg/errors

# ... nor can we run tests...

echo "\$ go test github.com/pkg/errors"
go test github.com/pkg/errors

# ... nor can we run tests...

echo "\$ go vet github.com/pkg/errors"
go vet github.com/pkg/errors

# ... nor can we install the package (imagine particularly if this were a main
# package)...

echo "\$ go install github.com/pkg/errors"
go install github.com/pkg/errors

# *******************************************************
# the go tool does not generally work on dep dependencies
# if we refer to them via their import paths
# *******************************************************

# instead we have to prefix the location of the vendor

echo "\$ go list -json $(go list)/vendor/github.com/pkg/errors"
go list -json $(go list)/vendor/github.com/pkg/errors

echo "\$ go test $(go list)/vendor/github.com/pkg/errors"
go test $(go list)/vendor/github.com/pkg/errors

echo "\$ go vet $(go list)/vendor/github.com/pkg/errors"
go vet $(go list)/vendor/github.com/pkg/errors

echo "\$ go install $(go list)/vendor/github.com/pkg/errors"
go install $(go list)/vendor/github.com/pkg/errors

(see the output)

In short, I think the go tool should work on a project's dependencies.

The main reason being that we then don’t need to work out/reinvent how to install, test etc those packages, the go tool continues to be responsible for such tasks.

Edit (2017-04-13): removed the term "controlled" per @sdboyer in favour of simply describing these packages as the "project's dependencies"