Vendoring always seemed a bit gross to me. On one hand it makes it possible to avoid build breakages when doing "go get" from master, but on the other hand it makes keeping up with master more difficult as it disassociates you from the source.

I think when multiple projects involve vendoring we will end up with cuts at arbitrary places in our dependency graphs, and knowledge and manual intervention will be required to sync with modern/bug-fixed implementations.

Someone gave me a good piece of advice on ethics once: if it's a problem when everyone does it, it's probably unethical.

In this case we want to make life easier on our users, but from those good intentions we may actually make an ecosystem where everyone is less efficient...

http://en.m.wikipedia.org/wiki/Price_of_anarchy

I would personally rather intervene once to lock the entire transitive closure in a buildable state rather than manually find and update all vendored cuts in the graph.

The plot will thicken with http://golang.org/s/go1.4-generate as I suspect the generate step will frequently refer to things in $GOPATH/bin.

I like what the go authors think about dependencies being backwards compatible, but not everyone thinks that way, and let's face it, people make mistakes and make incompatible changes unintentionally.

I started a project last weekend (still a WIP), go get version[1], that basically proxies the `go get` commands, but fools it into thinking the master branch is either a tag or a version to get around some of these problems, while aiming to still work with the go tool.

For example, if you have a tag named v1.0.3, you would change your import path to be something like this:

gogetver.com/github.com/user/project.v1.0.3

There's also gopkg.in[2] which does something similar, although it appears to only work with github.

[1]: https://github.com/rsenk330/gogetver [2]: http://labix.org/gopkg.in

Coming from npm, composer, bundler, and utilities like those I wasn't entirely happy with Godep. Instead there's Glide[1].

Sure, Godep lets you save and restore dependencies to your GOPATH. But, what if different projects with different versions of dependencies? Or, what if you want to track to branches?

There's a reason npm, bundler, and composer are popular. They are useful. That's why I've become a happy glide user (and contributor).

Just my 2 cents.

[1] https://github.com/Masterminds/glide

Thanks! I didn't know Glide, but I'm in love at first sight!

Any word on how you'd use glide during deployment? Say on a build machine, or when deploying to Heroku?

If you're looking for a Heroku buildpack to install your dependencies and build your binary I'm not aware of one. But, that would be a useful idea. Even something that could be used for Cloud Foundry as well.

On a build machine you'd do a `glide install` to get the dependencies installed, set the gopath (there are a couple ways to do it), and then go build per usual.

From there you can deploy the binary as needed.

Glide sounds pretty cool, but how is it better than just setting your GOPATH on a per-project basis?

Glide attempts to automate some of that. For example, Glide knows what your GOPATH for a project should be and using `glide in` your GOPATH is set. No needing to remember it. Using `glide install` will read the dependencies listed in the yaml file and install them while setting them to the specified version in the same place your GOPATH should be for the project.

It simplified GOPATH handling in addition to working with dependencies.

In that you don't have to set your GOPATH on a per-project basis?

I use godep for a couple of projects. It works pretty well. Sometimes the path rewriting feels a bit dirty though, and can make adding new imports/dependencies a bit of a chore.

For a couple of projects I was using godep with the `-copy=false` mechanism, and was sad to see it go. As a replacement for that functionality, I have had good luck with gpm[1]. I just put the build script in a build or tools dir (the script is quite small), and make it part of a make build invocation, to remove the external requirement.

[1]: https://github.com/pote/gpm

I've been waiting for a consensus to appear on Go dependency management. Finally I think we can call it - godep or something like it seems to be what works best.

Google said they were going to wait and see what approach worked best in practice before they integrated dependency management into the go tool. I think we're there now. The ball's in your court google.