News for hackers. Stuff that matters.
Re:Experimental Dependency Vendoring in Go 1.5 by AYBABTME on Thursday June 11, 2015 @12:03PM (#9700487)
This is pretty much what we've been doing at DO, but we were dealing with GOPATH manipulation to achieve it. By having `GOPATH="third_party/:docode/"`, `go get` pulls packages into `third_party` automatically, and `go install` finds our binaries in `docode/src/services/foosvc/cmd/foosvcd`.

Migrating to use `vendor/` instead of `third_party/` will be trivial, and not having to modify GOPATH will be nice.

Having a GO_VENDOR=1 env var on top of the `go get -vendor` feature flag would be nice, so that the feature works with minimal disruption.

Re:Experimental Dependency Vendoring in Go 1.5 by technoweenie on Thursday June 11, 2015 @02:20PM (#9701342)
How do you handle a custom GOPATH like that when the current repository needs to be in there too? We've tried manually symlinking the repo dir into the custom '$GOPATH/src/github.com/user/repo' dir, but it feels really hacky.
Re:Experimental Dependency Vendoring in Go 1.5 by anezvigin on Thursday June 11, 2015 @02:23PM (#9701364)
You can separate multiple paths with a colon.
Re:Experimental Dependency Vendoring in Go 1.5 by bradfitz on Thursday June 11, 2015 @07:02PM (#9703010)
More specifically, with os.PathListSeparator. (colon on Unix, semicolon on Windows and \x00 on Plan 9)
Re:Experimental Dependency Vendoring in Go 1.5 by lstoll on Thursday June 11, 2015 @03:19PM (#9701712)
We just keep all our go code in one repo.