A Roadmap to Merging 'dep' into the Go Toolchain

Re:A Roadmap to Merging 'dep' into the Go Toolchain by lobster_johnson on Friday March 10, 2017 @02:17AM (#13836942)

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?

[ Parent | on HN ]

Re:A Roadmap to Merging 'dep' into the Go Toolchain by michael-go on Monday March 13, 2017 @03:04AM (#13855780)

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

[ Parent | on HN ]