Hey guys,
we’ve used Godep for a long time at our company, but we had issues with multiple internal packages.
We’re now using gb, which is working great. I really like the ease of creating a few packages per project (for a web application: handlers, helpers, database, etc.). This de-clutters code and makes everything modular.
What dependency manager are you using in production? Custom vendor/ folder and go get, Godeps, gb or something else?
I started vendoring since GO15VENDOREXPERIMENT.
And found https://github.com/FiloSottile/gvt which is a simple Go vendoring tool based on gb-vendor.
It has worked great so far.
what problems did you have with godep? I’d like to fix them, or at least raise awareness of them.
I also recommend gvt. If you found a project-oriented dependency management tool, I would recommend gb.
@freeformz: We had another package in a subfolder and Godep kept copying it to it’s _workspace. I really like the gb concept.
I highly recommend gb as well, we use it across all our projects at PSG and it’s been a charm.
@hyper-carrot: gvt looks really great since it combines the go-like approach but with native support. Maybe I’ll use gb for projects with sub-packages and gvt for everything else. 
Thanks, gvt also looks great! 
Our team got frustrated with Godeps as well. We’ve been experimenting with govendor recently and it’s been working well. May be worth looking at if someone reads this and isn’t using gb.
@Jack Glad to hear your company is using govendor. There are outstanding feature requests in the issue tracker; let me know if any of those features would be useful for your workflow.
Hmm. Can you describe the layout better? I’d like to try to duplicate (or at least understand) what was happening.
I had a main package (top level) and a package in a subfolder.
Godep kept copying the subfolder to its _workspace.
I’ve been using glide (https://github.com/Masterminds/glide) with GO15VENDOREXPERIMENT to version lock dependencies. The process for pulling / building a repo with pinned dependencies is pretty easy for anyone else working on the project:
@awinograd I feel that glide may be pulling too much from other systems, especially interpreted languages.
With godep or govendor, you just run “go get github.com/user/myproject” and it is made, all dependencies and everything, with the executable in the bin folder already. They both have fewer/less complicated meta-data files then glide. Yes, like glide, govendor will “flatten” the dependency tree and record package revisions.
I have observed my own behaviour and whenever I stumble upon an interesting go project I’m far more likely to try it out if the installation instructions are to simply go get it. The more complex the install method the less likely.
Vendoring removes dependency management from user installation instructions. And with options like gvt, gb, glide and govendor hopefully more developers should vendor their projects.
So I’m very happy that the go community is embracing the vendor model of dependency management and a big thank you to the authors of the aforementioned tools.
@kardianos and @netixen,
Yeah, I get not wanting to do the extra step. I think where we really butt heads is whether or not to check dependencies’ source into version control
If we don’t check in the dependencies in to a vcs then we aren’t vendoring but just dependency managing with a manifest file right. And there’s nothing wrong with that.
Yep. That’s correct.
But what if GitHub went down? Everything would break at an instant.
