Why do I get an error about "no buildable Go source files" when I use "go get -d"?

[mrush...@pivotallabs.com]

I'm really confused about what "go get -d" is supposed to do. 

The docs state: 

The -d flag instructs get to stop after downloading the packages; that is, it instructs get not to install the packages.

The first time I call "go get -d", I get an error about no buildable Go source files; however, once those files have already been downloaded, the next call to "go get -d" succeeds.  I'm not sure if this is a bug in "go get" or if the documentation is incorrect or if I am simply misunderstanding something.  My expectation was that the first call to "go get -d" would have downloaded the package and would not complain about the lack of buildable Go source files, because it was not supposed to install the packages.

For context, our CI system calls "go get -d" with this particular project, and this means that the first build from a clean workspace will always fail because "go get -d" exits with code 1.

Can anyone help clear the air?

Here's the output showing specifically the issue I have:

vagrant@packer-virtualbox-iso:/tmp/go$ go version

go version go1.2 linux/amd64

vagrant@packer-virtualbox-iso:/tmp/go$ go env

GOARCH="amd64"

GOBIN=""

GOCHAR="6"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOOS="linux"

GOPATH="/tmp/go"

GORACE=""

GOROOT="/usr/local/share/gvm/gos/go1.2"

GOTOOLDIR="/usr/local/share/gvm/gos/go1.2/pkg/tool/linux_amd64"

TERM="dumb"

CC="gcc"

GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"

CXX="g++"

CGO_ENABLED="1"

vagrant@packer-virtualbox-iso:/tmp/go$ ls -al

total 8

drwxrwxr-x  2 vagrant vagrant 4096 Jan 17 16:07 .

drwxrwxrwt 14 root    root    4096 Jan 17 16:07 ..

vagrant@packer-virtualbox-iso:/tmp/go$ time go get -d github.com/pivotal-cf-experimental/cf-acceptance-tests; echo $?

package github.com/pivotal-cf-experimental/cf-acceptance-tests

imports github.com/pivotal-cf-experimental/cf-acceptance-tests

imports github.com/pivotal-cf-experimental/cf-acceptance-tests: no buildable Go source files in /tmp/go/src/github.com/pivotal-cf-experimental/cf-acceptance-tests

real 0m7.984s

user 0m0.152s

sys 0m0.104s

1

vagrant@packer-virtualbox-iso:/tmp/go$ ls -al

total 12

drwxrwxr-x  3 vagrant vagrant 4096 Jan 17 16:07 .

drwxrwxrwt 14 root    root    4096 Jan 17 16:07 ..

drwxrwxr-x  3 vagrant vagrant 4096 Jan 17 16:07 src

vagrant@packer-virtualbox-iso:/tmp/go$ time go get -d github.com/pivotal-cf-experimental/cf-acceptance-tests; echo $?

real 0m0.021s

user 0m0.000s

sys 0m0.020s

0

[Carlos Castillo]

"go get -d", is run with the path github.com/pivotal-cf-experimental/cf-acceptance-tests, which contains no go code. Go get doesn't know that until after it downloads it. The reason a go package needs to be found there, is because it will try to recursively download the dependencies of it.

The second time, there is already data in the place it would have downloaded to, so to avoid overwriting the directory, or redundantly downloading code, it stops operation immediately. If you really want to see a second error, pass the -u flag to go get (to force a re-download).

Otherwise, pass a path that actually contains go code. Note that only the dependencies of the valid packages you pass will be downloaded (not all dependencies of all packages in the repo).

Alternatively, to download all dependant code of all packages in the repo: go get -d github.com/pivotal-cf-experimental/cf-acceptance-tests/...

[Carlos Castillo]

Further, to clarify:

go get's arguments (barring the use an ellipsis wildcard) are packages, not repositories, and not directory trees. The potential package github.com/pivotal-cf-experimental/cf-acceptance-tests is not valid, since it has no *.go source files in it.

On Friday, January 17, 2014 4:20:31 PM UTC-8, mrush...@pivotallabs.com wrote:

[mrush...@pivotallabs.com]

I was muddling packages and repositories together. That extra clarification helped me understand what I was missing. Thank you.

That repository has no go files in the root folder, but its subfolders do contain go code, so in my case adding the ellipsis resulted in the desired effect of being able to run "go get -d github.com/pivotal-cf-experimental/cf-acceptance-tests/..." without an error the first time.