[lobster_johnson]

You say you don't want the go tool to be more complex -- but gopkg.in just moves dependency management elsewhere. You have to have it somewhere.

gopkg.in only works properly if everyone uses it. The second you have a non-gopkg.in package, you have no way to manage that dependency.

Does gopkg.in work for non-public libraries?

[michael-go]

another problem with gopkg.in it uses only the major version number and you can't import a specific minor version. what if version 2.5 works great but 2.6 breaks something for you? you can't use pkg.in until this issue is resolved in 2.7 .. and most package authors don't want to bump the major version on every change ..