I get the same error message and failure exit every time if I add the -u option to the "go get" command:

$ go get -d -u golang.org/x/tools

Thanks,

William

go get is for fetching packages, not repositories. golang.org/x/tools is the root of the tools repository, so go get golang.org/x/tools will succeed in checking out the repository but then fail as it tries to build tools package (as there is no such package).

This explains why -d works, as it only tries to download the package but doesn't try to build.

I'm not sure why go get -d -u should be different to go get -d in its error state. Maybe that's a bug?

My thinking was that without -d it should try to build, but with -d it should download only, so "go get -d" and "go get -d -u" should not have an error state if they download the repository. However, "go get" or "go get -u" should have the error state if they try to build.

@adg:
I'm not sure how clear I was in my original description of this issue, so I want to show the sequence of commands I ran along side my questions:

GOROOT is /usr/lib/go

$ rm -fr /home/William/go
$ mkdir /home/William/go
$ export GOPATH=/home/William/go
$ cd /home/William/go
$ go get golang.org/x/tools # this fails because tools is not a package, that makes sense.
$ rm -fr src/golang.org
$ go get -d golang.org/x/tools # Why does this fail the same way as go get without -d?
$ go get -d golang.org/x/tools # Running this a second time in a row succeeds
$ rm -fr src/golang.org
$ go get -d -u golang.org/x/tools # Why does this fail like go get without the -d?
$ go get -d -u golang.org/x/tools # Running this a second time in a row fails the same way, why?

Does all of this make sense?

Yep, it makes sense. The fix is probably quite subtle. We might get it fixed for 1.5; let's see.

I found a way around this that is even more subtle than I thought after experimentation with our packages in Gentoo. If you add "/..." to the end of a repository name, things work as expected, e.g.

$ go get -d -t -u -v golang.org/x/tools/...

Doing this makes "go get" not complain about non-buildable sources at the top level.

So is this just a documentation issue? I didn't see anything about it in "go help" anywhere.

The /... means that it will match the packages inside that repo, so it makes sense that it works.

I don't think it's just a documentation issue. I think there's a subtle difference in how -d is treated depending on whether -u is specified, and that is not intentional and should be fixed.

They should both fail.
Even with -d, the command needs to read
the package sources to find out what the dependencies are,
since -d also fetches dependencies recursively.
So errors like not having any source files still surface.
The bug is that get -d (without -u) succeeds.
Will fix.

CL https://golang.org/cl/12177 mentions this issue.