[poofyleek]

I use gopkg.in. Personally I would like to see the community avoid adding more to the 'go' tool. It is already doing too much. I think the solution provided by gopkg.in is better than other more conventional methods (e.g. npm or maven like). I love Go. But it is ironic that 'go fmt' was designed in from the beginning. And now we are still dealing with semver and package dependencies. I went with gopkg.in because it made the dependencies a non issue from the tooling point of view. It is made possible by having 'import' direct from the repositories, which archive different versions and tags. Perfect for something like gopkg.in. I am probably in the minority.

[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 ..