Migrate from glock to govendor

[maddyblue]

[bdarnell]

I am strongly opposed to checking in a snapshot of all our dependencies' source like this. It bloats the repo and makes it difficult to make local changes in a way that can be contributed upstream. My preferences (in order) would be:

1. Use some tool to pull in the dependencies at build time like glock does
2. git submodules
3. git subtree (which still bloats the repo but has better tracking of upstream revisions)

[tamird]

+1 for the same reasons.

On Wed, Feb 24, 2016 at 5:22 PM, Ben Darnell notifications@github.com
wrote:

I am strongly opposed to checking in a snapshot of all our dependencies'
source like this. It bloats the repo and makes it difficult to make local
changes in a way that can be contributed upstream. My preferences (in
order) would be:

1. Use some tool to pull in the dependencies at build time like glock
   does
2. git submodules
3. git subtree (which still bloats the repo but has better tracking of
   upstream revisions)

—
Reply to this email directly or view it on GitHub
#4620 (comment)
.

[maddyblue]

Ok. Never mind I guess. I have zero interest in using git trickery. I think doing the first suggestion there (pulling in at build time) is wrong, because to me one of the major benefits of having the code in the repo is being able to create reproducible builds. I don't care about the repo bloat at all. It's just some more files. The upstream thing is true, but I think the benefits outweigh those issues.

[kardianos]

Remote dep fetch and sync is on govendor roadmap. Next item actually. This is one of the projects I will ensure works with current workflow.

Benefit over glock is use of vendor folder, which lets you share GOPATH with other projects.

[maddyblue]

@kardianos Thanks. Can you either update this issue or provide one for us to track so we can try it out once it's done?

[maddyblue]

https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.vz5v94ygo is exactly why I think vendoring is a great idea. If we don't put all of the code into our repo, we can get into a situation exactly like this where cockroach is unbuildable from a fresh $GOPATH because someone just decided to unpublish their code.

[abh]

+2 on vendoring. The current scheme is really unfriendly to new users. In my experience it also has a side-effect of not appreciating the cost of adding dependencies; as a developer it feels too cheap to add "just one more".

[dt]

@abh there's another vendoring PR out that takes a slightly different approach -- adding a submodule -- but achieves mostly the same results: #8618