4 ms·

Current Go users, What's the state of package versioning right now? Is vendorization still the answer?

by lbotos 12y ago

ansible 12y ago
In my opinion, yes, vendor-izing your dependencies is the way to go. My preferred way to do that is to use git subtree.
collinvandyck76 12y ago
Yep. Either through godep or a VCS-native solution like git submodules or git subtrees.
AYBABTME 12y ago
There are other ways around, but I'd say the community is solidifying towards godep. Someone correct me if I'm wrong.
leef 12y ago
No need to vendor. Use Godep without copying (godep save -copy=false) to create the equivalent of a bundler.lock file and check that into source.
joncooper 12y ago
Another +1 for godep.
mediocregopher 12y ago
Also, for variety (and a shameless plug), check out: https://github.com/mediocregopher/goat https://github.com/mediocregopher/goat
CMCDragonkai 12y ago
Check out gom, it's really popular too.
jsmthrowaway 12y ago
godep is winning and works well, but I still think there's an opportunity for something like a Go-flavored CPAN.
dayjah 12y ago
We use Godep, it is very good. As per another answer to your question: with '-copy=false' it behaves a lot like bundler.lock. Having spent a lot of time working with it we've found a few areas where you can get burned a little; particularly if you've structured your repos as a set of libraries, as seems to be the encouraged golang pattern. When you have multiple libraries you have to be very specific about when you run godep, lest you find yourself with two libraries needing different versions of a common library, for example Main imports Foo and Bar, which both import Baz. Godep provides a mechanism for handling this: each dependency is explicitly locked into a fixed revision (e.g. commit sha, in the case of git). The pain comes about when during debugging as it can be very hard to reason which version of a library you're using. Additionally the revision aspect is also a bit of a PITA, we use a development flow which rebases our small commits into a big commit and then merges that into our master branch; if you ran godep prior to that you're now referencing a commit that no longer exists. Given the chain of references that can exist this can go a very long way down. This same pattern also forces you into needing to push your dev branches to an origin server, as godep checks out the repos during the build, which while pretty benign a concern is a PITA if you forget and your build breaks because of it. We're strongly considering moving to "one big repo" to help combat this issue (as well as a few others) for our internal golang repositories. Referencing "published commits" in 3rd party libraries is an acceptable level of pain. We're not entirely sold on this yet... just considering it.
chimeracoder 12y ago
There seem to be a lot of comments here recommending godep, but just to throw my experience in: none of the projects I've interacted with use godep (other than the Heroku buildpack, which was written by the author of Godep). It seems to be a solution for some (not all) projects that are released in binary form, but that isn't relevant to most projects out there[0]. I have never felt the need for what godep provides; vendoring myself has been sufficient for the (very rare) case in which I need specific versions of dependencies other than tip/trunk. I asked around on #go-nuts, and (though the sample size was small), the other regular contributors who idle in the channel seemed to have the same experience. YMMV obviously. [0] https://botbot.me/freenode/go-nuts/2014-06-19/?msg=16563763&page=7 https://botbot.me/freenode/go-nuts/2014-06-19/?msg=16563763&...

Current Go users, What's the state of package versioning right now? Is vendorization still the answer?

by lbotos 12y ago

Current Go users, What's the state of package versioning right now? Is vendorization still the answer?

ansible 12y ago

In my opinion, yes, vendor-izing your dependencies is the way to go. My preferred way to do that is to use git subtree.

collinvandyck76 12y ago

Yep. Either through godep or a VCS-native solution like git submodules or git subtrees.

AYBABTME 12y ago

There are other ways around, but I'd say the community is solidifying towards godep. Someone correct me if I'm wrong.

leef 12y ago

No need to vendor. Use Godep without copying (godep save -copy=false) to create the equivalent of a bundler.lock file and check that into source.

joncooper 12y ago

Another +1 for godep.

mediocregopher 12y ago

Also, for variety (and a shameless plug), check out: https://github.com/mediocregopher/goat https://github.com/mediocregopher/goat

CMCDragonkai 12y ago

Check out gom, it's really popular too.

jsmthrowaway 12y ago

godep is winning and works well, but I still think there's an opportunity for something like a Go-flavored CPAN.

dayjah 12y ago

We use Godep, it is very good. As per another answer to your question: with '-copy=false' it behaves a lot like bundler.lock. Having spent a lot of time working with it we've found a few areas where you can get burned a little; particularly if you've structured your repos as a set of libraries, as seems to be the encouraged golang pattern. When you have multiple libraries you have to be very specific about when you run godep, lest you find yourself with two libraries needing different versions of a common library, for example Main imports Foo and Bar, which both import Baz. Godep provides a mechanism for handling this: each dependency is explicitly locked into a fixed revision (e.g. commit sha, in the case of git). The pain comes about when during debugging as it can be very hard to reason which version of a library you're using. Additionally the revision aspect is also a bit of a PITA, we use a development flow which rebases our small commits into a big commit and then merges that into our master branch; if you ran godep prior to that you're now referencing a commit that no longer exists. Given the chain of references that can exist this can go a very long way down. This same pattern also forces you into needing to push your dev branches to an origin server, as godep checks out the repos during the build, which while pretty benign a concern is a PITA if you forget and your build breaks because of it. We're strongly considering moving to "one big repo" to help combat this issue (as well as a few others) for our internal golang repositories. Referencing "published commits" in 3rd party libraries is an acceptable level of pain. We're not entirely sold on this yet... just considering it.

chimeracoder 12y ago

There seem to be a lot of comments here recommending godep, but just to throw my experience in: none of the projects I've interacted with use godep (other than the Heroku buildpack, which was written by the author of Godep). It seems to be a solution for some (not all) projects that are released in binary form, but that isn't relevant to most projects out there[0]. I have never felt the need for what godep provides; vendoring myself has been sufficient for the (very rare) case in which I need specific versions of dependencies other than tip/trunk. I asked around on #go-nuts, and (though the sample size was small), the other regular contributors who idle in the channel seemed to have the same experience. YMMV obviously. [0] https://botbot.me/freenode/go-nuts/2014-06-19/?msg=16563763&page=7 https://botbot.me/freenode/go-nuts/2014-06-19/?msg=16563763&...