The best dependency manager

[netixen]

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.

[arne (Arne Bahlo)]

I agree

[diego.bernardes]

im using gvt, its amazing.

[abourget (Alexandre Bourget)]

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 github.com/abourget/godef

[mattfarina]

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.

[hiromaily]

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.

Thanks.

[calmh (Jakob Borg)]

You should probably look into gb. It supports vendoring similar to Godeps today, but it looks like it’s planned to allow “partial vendoring” where important packages can be vendored and other dependencies fetched automatically similar to how “go get” does it (but smarter, with version awareness).

[hiromaily]

Thanks for useful advice. I try it.

By the way, I think, option of go get command and import features are deficient.
For example, I’m using aws/aws-sdk-go package. But needed version is v0.9.17 on specific projects.
I use that command in aws/aws-sdk-go directory.
$ git checkout v0.9.17

Tag feature of git may be useful. If that feature can be combined with golang, I could expect as below.
Let’s say go get command can be use another option ‘tag’ or so, and then
$ go get -tag v0.9.17 github.com/xxxxx/xxxxxx
-tag option indicates tag version of that git repository.
that command can change tag version on specific git repository after fetch.
After fetch, the below command can be carried out.
$ git checkout v0.9.17

import syntax would be necessary as well.
For example, if import could be like import github.com/xxxxx v0.9.17
Architecture are similar to previous one.

I know it’s not perfect, but radical improvement may be requisite instead of depnding on management tools.

[calmh (Jakob Borg)]

@hiromaily

option of go get command and import features are deficient

Indeed. Hence all the vendoring tools and package managers. There’s been a lot of thinking done about this and a lot of proposals rejected. Personally I think the route gb is taking looks like the best way forward. If gb becomes the de facto standard build tool, and it supports a reasonable form of versioning, we’re good to go.

[kardianos (Daniel Theophanes)]

@calmh Nothing against gb, but for the sake of the thread I’d like to be clear that gb is fundamentally a project based build tool (as opposed to a GOPATH based build tool), not a vendoring tool. It is true that gb comes with gb-vendor which provides vendoring for the gb workspace.

@hiromaily If you are looking for a tool today that only copies packages you reference into the vendor folder, that is exactly what govendor does today. What it doesn’t do today is to fetch specific versions though that is planned.

As far as “get get” integration or an official method, there has been a bit of discussion on this topic and many people have many opinions. I am a proponent of a single meta-data file that contains revisions, versions, and version ranges. That can be used by tools. Should we get down to a fairly standard design and meta-data file, perhaps we could see integration into the “go” command.

[filippo (Filippo Valsorda)]

Hi! gvt author here. I’m super happy to see people using my little port of gb-vendor!

Please feel free to report any feedback or anything I can do to make gvt better either here, on the GH Issues, or at gvt -at- filippo.io.

If you are here looking around for what tool to use I tried to explain why you might want to use gvt in the README: https://github.com/FiloSottile/gvt#gvt-the-go-vendoring-tool