Hacker News Reader

Comment by LanceH | Hacker News Reader

How do people differentiate between packages being worked on and packages installed?

Let's say I have my-package (version 1.0) installed and in use in a lot of my other projects. But I'm working on version 1.1, but need to have 1.0 as the reference for other projects.

Right now I just fiddle with $GOPATH but that feels like a hack and is an annoyance if I have to swap around a bit.

Right now my-package might be in a broken state because I'm working on it, so I can't build anything relying on it if I go with the single $GOPATH hierarchy that every discussion seems to assume.

View on HN

My main method of keeping track of this is creating a symlink to all my actual projects in my regular ~/work directory. Appart from this most people use vendoring, but I use (and maintain) virtualgo instead: https://github.com/GetStream/vg

It supports working on a dependency of a project locally with ease, by using "vg localInstall" which is a extreme pain with vendoring. And also it supports version pinning of executables.

Generally we use vendoring, i.e. you have 1.1 in your gopath, but vendor 1.0 in your projects (as long as they're standalone projects).

It's also important to limit cross package dependencies as much as possible to avoid these situations.

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

[1] https://github.com/golang/dep

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.

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.

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.

0. They could use something like "kardianos/govendor" to check the location of the used packages (vendor, internal, external ...). 1. Using environment variables is not a hack in general. Persisting the environment in version control requires some kind of make-like wrapper though. 2. $GOPATH is not limited to one directory.

Reply on news.ycombinator.com