Experimental Dependency Vendoring in Go 1.5

[NateDad]

I really like this proposal. It's basically the best of all current dependency tools - you get reproducibility without needing external configuration files, without hugely long vendor import statements, and still supporting raw go-get.

[AYBABTME]

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.

[technoweenie]

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.

[lobster_johnson]

Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder?

In other words, you would still want something like godep or gb, because manually copying dependencies into a folder (or using git submodules, ugh), and then tracking their versions through their lifecycle, isn't a workable solution in most situations.

This is clearly an improvement over "go get", but I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself.

Go is so opinionated about so many things, and yet so little interested in having a strong opinion here. The Unix philosophy is great, to be sure, but the Unix philosophy is about increasing modularity through simplicity, and this problem is about modularity.

[rsc]

Is the criticism here really that we have declined to express a strong opinion about something we don't know a lot about?

[enneff]

> Am I correct in thinking that this proposal only lays the foundation for other tools to actually manage the vendor folder?

Yes.

> I don't understand why Go is so insistent that dependency management is something for the community to solve

Well, they solved it, and now we are beginning to adopt their solution. Seems to be working.

[twblalock]

> I don't understand why Go is so insistent that dependency management is something for the community to solve

The expectation that every new language should come with a dependency management ecosystem is a bit questionable. A lot of major languages' dependency management solutions were created by the community:

Java: Maven, Gradle

Python: PIP

Ruby: Gems

Node.js: NPM

Some of these have been adopted by the official language maintainers, but as far as I know, they originated in the community.

[vruiz]

> I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself.

They don't want to try solving a problem they don't really have. As RSC says:

> the community understands and encounters these problems more than we on the Go team at Google do.

[vruiz]

This is nice. Finally it seems like we are going somewhere. The call for proposals had not yielded anything groundbreaking so far. Tools like gb are nice but as Russ says it's not gogettable. This seems like a good compromise.

[drewolson]

Am I understanding correctly that this proposal again side steps / ignores pinning dependencies for libraries? To me, this is the biggest current problem in the ecosystem and, as a library author, this doesn't solve any of my issues. I hope I misread somehow.

[enneff]

With this scheme libraries can vendor their dependencies, if necessary.

[Lethalman]

How we solved it in Nix: http://lethalman.blogspot.it/2015/02/developing-in-golang-wi...

We don't need go get or any other tool, and we have about 174 packaged libraries in our repository.

[ngrilly]

This is a great and necessary improvement. Being able to vendor dependencies without having to rewrite import paths is like having the best of both worlds.

The proposed mechanism looks similar to what Node.js does with the node_modules directories:

https://nodejs.org/api/modules.html#modules_loading_from_nod...

[wumbernang]

That's really nice.

This is a royal PITA with .net and nuget and I've get to find a half decent solution that allows you to actually have the source rather than a bunch of symbol-less dll dependencies or a ridiculous build stack.

[romanovcode]

Since MVC6/VS2015 beta you can actually get the source instead of dlls. However your build times will increase dramatically so it's a bad idea unless very needed.

[0xdeadbeefbabe]

A vendors B and C, but C vendors D and E. According to this proposal do you lay out the files like this: (A (vendor (B C D E)))?

Edit: I guess HN tree markup is not working :)

[jooon]

Yes. That would work. However, I also believe this will work: (A (vendor (B (C (vendor (D E)))))).

https://groups.google.com/d/msg/golang-dev/74zjMON9glU/LjrVU...

https://groups.google.com/d/msg/golang-dev/74zjMON9glU/0e7M7...

https://groups.google.com/d/msg/golang-dev/74zjMON9glU/qGzsS...