go-marathon
go-marathon copied to clipboard
gambol99
Vendor dependencies
We currently use go get to pull in dependencies and thus rely on HEAD-level compatibility for all third party packages. With vendoring becoming the default mechanism in Go to manage and pin dependencies, I suggest to introduce that in order to provide some means of protection from breaking and more subtle, non-breaking upstream changes.
FWIW, my organization happened to have reviewed a number of tools fairly recently, looking at godep, govendor, and glide in detail. We didn't like glide for a few reasons and couldn't use godep due to the way our repository is structured, and eventually went with govendor which was both fairly simple to use and provided most useful features. Personally, I'd be happy to go either with that or godep, possibly preferring the latter slightly more since it seems to be more wide-spread, comes with all necessary features, and might be easier to use by contributors.
Assuming we agree on the usefulness of vendoring our dependencies, do people have opinions on what tool we should use?
I ran across Peter Burgon's updated blog post on Go best practices where he explains that vendoring dependencies in libraries is often a bad thing to do. (Follow the included links for details. It boils down to exports of the vendored dependencies not being accessible by consumers anymore.) However, there's an exception for libraries that can manage to hermetically seal their dependencies (i.e., use them internally only and not export anything). We'd need to double-check where go-marathon stands in this regard.
I also gained a few more insights into existing vendor tools:
- Some folks at Kubernetes are very much in dislike of godep mostly claiming its opaque nature to complicate things a lot. They are striving to move to glide.
- I played around with glide and mostly liked it. One big caveat I saw is that it pulls in dependent packages completely whereas other tools like govendor trim things down to the necessary minimum. With a smallish Kubernetes client of mine, glide pulled in over 80 MBs of dependencies while govendor needed 10 MB only.
- gvt might be another interesting candidate.
@timoreimann I really like glide (and we use it for all Go projects at Strava). I see your criticism, but it is also easy to setup and understand.
@mlerner Thanks for your input. To me, glide actually seems somewhat more complicated to use and understand compared to govendor, something I mostly attribute to the fact that glide comes with more features. That said, I don't think the gap is too wide.
The main concern I raised regarding vendor directory size in glide is probably not going to matter a lot for go-marathon, so I'd be happy to move forward with it (presuming the library vendoring constraint mentioned above doesn't apply for us, of course).
I really like the vendor functionality of gb, which I understand is what gvt is based on. So +1 for gvt :)
Hi I have used gvt for a while and I liked it, mainly for it simplicity and usability compared to glide. I think the project should maintain his simplicity.
