Hacker News Reader

Comment by rocmcd | Hacker News Reader

Yes, vendoring is the best choice here. I'd also recommend everyone give dep[1] a shot.

Having tried to migrate from godep to dep a couple of times now I always gave up seeing how many additional unneeded files dep will pull into my /vendor folder.

Just a few days ago using dep instead of godep on a medium-sized web application gave me a delta of 1,920,834 additions and 1,942 deletions (_after_ manually pruning _test files), mostly caused by depending on aws-sdk-go.

Do you have any strategy for keeping your vendor small with dep or do you just accept it the way it is?

There seems to be this: https://github.com/golang/dep/issues/858 , but it looks like it's not implemented yet and the status is highly unclear.

Running "dep prune" after "dep ensure" should remove a lot of unnecessary files (this will be integrated into ensure somewhat soon). Also, in a lot of cases it's not needed to commit the vendor directory, so its size doesn't really matter then. Finally, I really recommend checking out the #vendor channel on the Go slack if you have any more questions regarding dep, everyone there is really helpful.

Do you have production applications running that do exclude their vendor folder? Does this work reliably? How do you handle dependencies that do not use semver?

What would be one of the cases where you'd say you need to commit vendor?

All our production applications don't have their vendor committed. By running "dep ensure" it dep restores the exact same vendor directory from the lock file, we do this in CI where we build our binaries. For dependencies that don't support semver dep uses the master branch by default and pins a commit to support reproducible builds. The only case where this has caused problems for us was when one of our dependencies force pushed to master, so the commit that was pinned didn't exist anymore. This resulted in a failing build though, not an inconsistent one.

Other than working around that issue the only case where you actually need to commit vendor (at the moment) is when you want your project to compile reproducibly by only running "go get project". If you are fine with telling your user to run "dep ensure" (or make) first this is not needed. This is not usually an issue when working with colleagues, but can be nice for publicly released projects.

Thanks for all the insights! I will give this a go soon I guess.

No, I've mostly accepted it at this point since I don't care too much about the size of /vendor (as long as it's not outrageous). I have noticed that it brings in extra files, though, which a `dep prune` typically helps alleviate.

Reply on news.ycombinator.com