go1.5 vendoring experiment -- what tools work well with it?

[Tim K]

What tools do you find useful with the experimental vendoring support in Go 1.5? Things like godep, etc. that can compliment vendoring support and that work well with it.

Or do you do it all by hand?

[parais...@gmail.com]

people here point to glide , never used it though.

[Yejezkel Reyes Pernas]

i saw an article pointing to:

https://github.com/Masterminds/glide

i don't know if its production ready but it looks very similar to the "vendoring experiment"

[Daniel Theophanes]

I use and made https://github.com/kardianos/govendor

[Tim K]

Thanks Daniel. Could you please say a few words about vendor-spec? Is it officially worked on by the Go team? I see it mentioned in this doc, once, but it's not linked to anything, so I'm not sure what it all means.

https://golang.org/s/go15vendor

[Daniel Theophanes]

Sure Tim.

Go aims for convention over configuration often. But for different tools to talk sometimes it is useful to describe a common specification. The go compiler and the gccgo compiler do this with the go spec. More recently the "vendor" folder is now an experimental convention that is supported by the go tool, when accepted, will be adopted by the other tools as well. The vendor-spec proposal aims to describe the dependencies in the "vendor" folder. It is still in flux though in the next few weeks it should probably stabilize.

I can't speak for the core go team. However the main go repository and some of golang.org/x/ repositories have both begun to use the "vendor" folder and Russ has added in a vendor.json file by had to one of the vendor folders. 

Lastly, I can't stress enough that go's dependency management is fundamentally different then many other languages. Ruby and Python both need dependencies to be resolved on the client. Even Java and C# often allow dependencies to be described and obtained after compiling. Due to the implementation of Go's static linking Go's dependency management story will look different when we try to optimize it I believe. Even with shared library support dependencies management will look much more like C's (operating system provided) then say pip or Maven.

...

This is one of several efforts by community members to try to make the Go ecosystem better. You will notice that the vendor-spec has "revision" but not "version" Dave has a proposal that suggests using a consistent version schema (semver2) to release packages.  (While I do not endorse that particular proposal I do think it is a reasonable conversation to have as next steps.I believe the proposal fails to state assumptions it builds on and the end goals sufficiently, it also dismisses mono-repos and larger combined repos out of hand.)  As such in the future there may also be a defined "version" field with a reasonable meaning as well.

-Daniel

[Matt Farina]

I'm one of the devs of Glide.

Glide is setup to help those using the vendor experiment. We're driving to a 1.0.0 release and it's more about support feature additions. We want to fill the gap in tooling for those needing to manage packages and are trying to complement the `go` toolchain. If the `go` tool has a feature we don't want to implement it, too.

I think it's ready for production use. Since it relies on the vendor experiment the heavy lifting of loading packages is there. If you want to switch tools there shouldn't be a problem since the API to compiling the packages is part of Go.