We were excited enough we pivoted glide, the package manager, to directly support this new vendor setup.
Anyone interested can learn more at https://github.com/Masterminds/glide or where I posted about it at http://engineeredweb.com/blog/2015/glide-0.5-go-vendor-suppo....
I'm hopeful for this brave new vendor world.
Is there any scoping on what vendoring means for forking projects? i.e. if I pull something full of packages like domain.com/user/pkg, would I now be better served just dropping the whole subdirectory tree in a /vendor/ directory?
Can't seem to get this to work no matter what I do. And yes, I've set the GO15VENDOREXPERIMENT=1 env variable.
https://go-review.googlesource.com/#/c/10923/
Go 1.5 vendor proposal:
If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.
When there are multiple possible resolutions, the most specific (longest) path wins.
The short form must always be used: no import path can contain “/vendor/” explicitly.
Import comments are ignored in vendored packages.