> Godep works differently than the endorsed approach…
> Instead of requiring changes to be made to the source
> code to support the vendored import path, the GOPATH is
> modified to use the vendored folder.
This isn't correct — Godep has two modes, and this is just one of them. The other way is indeed rewriting import paths.
This is incorrect on another level, too. Rewriting import paths isn't "endorsed" by the Go authors. In fact, Russ Cox, in his GopherCon 2015 keynote, explicitly noted that
> Our basic proposal was that all tools agree on the
> approach of rewriting import paths during vendoring...
>
> [But] the community spoke with essentially one voice to
> say that rewriting import paths during vendoring was not
> tenable...
>
> Keith Rarick posted an alternate proposal for a minimal
> change to the go command to support vendoring without
> rewriting import paths . . . That proposal will ship as
> an experimental feature in Go 1.5 and likely enabled by
> default in Go 1.6.
Dependency management in Go is an ongoing sore spot, but there's light at the end of the tunnel, in the form of the referenced proposal[0], its spec[1], and the third-party tool gb[2]. Godep was a good intermediate solution, but it should no longer be recommended as something worth exploring.
[0] https://blog.golang.org/open-source
[1] https://github.com/kardianos/govendor
[2] http://getgb.io
This is incorrect on another level, too. Rewriting import paths isn't "endorsed" by the Go authors. In fact, Russ Cox, in his GopherCon 2015 keynote, explicitly noted that
Dependency management in Go is an ongoing sore spot, but there's light at the end of the tunnel, in the form of the referenced proposal[0], its spec[1], and the third-party tool gb[2]. Godep was a good intermediate solution, but it should no longer be recommended as something worth exploring.[0] https://blog.golang.org/open-source
[1] https://github.com/kardianos/govendor
[2] http://getgb.io