[dengnan]

Normally, when I see a directory named "src/" in a Go project's repo, it usually means the project is not quite idiomatic to Go.

To quote from Go's blog post [0]:

Sometimes people set GOPATH to the root of their source repository and put their packages in directories relative to the repository root, such as "src/my/package". On one hand, this keeps the import paths short ("my/package" instead of "github.com/me/project/my/package"), but on the other it breaks go get and forces users to re-set their GOPATH to use the package. Don't do this.

And this project is currently practicing the anti-pattern mentioned above.

0. http://blog.golang.org/organizing-go-code

Edit: format

[Jonhoo]

While I wish it was this simple, not having your application be "GOPATH ready" (i.e. allowing it to be directly set to be GOPATH) makes a lot of other things harder. For example, build and benchmark scripts that need to compile the application from source (and thus can't necessarily use `go get`), now need to take care to construct two parent directories before checking out the code. The fact that go doesn't follow symlinks when building doesn't make things easier either. It also forces you to file away your projects deep in your $GOPATH directory, rather than organizing them in other (better) ways and then linking them into your $GOPATH.

[andrewchambers]

This isn't an antipattern for large standalone programs which want to track all dependencies. But it is for libraries and small applications that should be quick to fetch.