The best dependency manager

@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. :+1:

Thanks, gvt also looks great! :grin:

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: Thanks for the suggestion, I will look into govendor! :relaxed:

@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 ( 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:

  1. git clone repo
  2. go get
  3. glide update
  4. go build
1 Like

@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” 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.

1 Like

@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.

I think of it this way:
If my project depends on 3rd party open source libs, vendor it.
If my project depends on libs under my control on github or company vcs, managing with a manifest is fine.

I agree :slight_smile:

im using gvt, its amazing.

I use git subtree… so I can easily pull back aome changes in upstream repos. Subtree also tracks some metadata in the commits. I found no use of an external vendoring tool. I need GO15VENDOREXPERIMENT though… which is great.

The problem I had with other tools is they would break editor tools (gocode, godef)… so I forked godef to support the vendor experiment at

It’s worth noting the features we’re backing into Glide aren’t just widely used in the interpreted language space. Tools like Cargo (for the Rust language) and Cocca Pods (for OS X) for compiled languages have these same features. We’re looking to have the same feature set as the mature tools in the same space for other languages.

I’m usign Godep for dependency manager.
It seem to work well. But I want to save only specific packages needed dependency management such as aws related packages. Because Godeps have to save all imported packages. But there may be own project’s packages as well in saved ones.
If so, those files will be modified as necessary and save command of Godeps have to be used each time after changing some files.
It would be troublesome for me.

If saving only specific packeages will be feasible, we’d get more easeful development.