
Godep for End User Go Projects - alexk
https://coreos.com/blog/godep-for-end-user-go-projects/
======
jshute
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](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](http://golang.org/s/go1.4-generate) as I
suspect the generate step will frequently refer to things in $GOPATH/bin.

------
rsenk330
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](https://github.com/rsenk330/gogetver)
[2]: [http://labix.org/gopkg.in](http://labix.org/gopkg.in)

------
mfer
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](https://github.com/Masterminds/glide)

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

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

------
stock_toaster
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](https://github.com/pote/gpm)

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

