vendor: follow golang/dep best practice

[gyuho]

#9155 (comment)

1. it's redundant, and potentially harmful, to specify source in Gopkg.toml when it's not actually needed (and it's not in any of the cases i saw from skimming).
2. unless there's a specific reason that you need exactly those revisions for all those projects, and that they NEVER change under ANY circumstances, it's preferable that you instead just specify e.g. branch = "master", and trust Gopkg.lock to give you the version stability you want.
3. v0.4.1 of dep prunes automatically, and you have more granular controls over it from within Gopkg.toml.
4. overrides should also be avoided, when possible. they can be useful as a one-time way of getting Gopkg.lock to the right place, but once you've done that, you should ideally be able to remove them.
5. strongly prefer released versions to go get-ing tip. we should have a curl-able installer soon Install.sh script for dep golang/dep#1533

ref. #9258

[fanminshi]

@gyuho is this emergent? I would like a deep dive in go dep when I come back.

[gyuho]

@fanminshi No, feel free to take this :)

[gyuho]

#9155 (comment)

There are some really unfortunate side effects as a result of this. For instance, cockroachdb wants to use a newer version of gogo/protobuf than what's specified in your new Gopkg.toml - the result is that dep will refuse to ignore etcd's specified version and won't resolve (in the presence of the two constraints etcd.branch = master and protobuf.branch = master).

As far as I know, there's no workaround here, other than for etcd to be very careful to not over-constrain your dependencies (and currently they appear to all be maximally constrained; your Gopkg.toml is roughly equivalent to your Gopkg.lock).

/cc @tamird

[sdboyer]

(moving discussion here from #9155)

@sdboyer yeah, that seems to work, but requires an override for every overlapping dependency (of which github.com/gogo/protobuf is just one).

@tamird indeed, having to make that number of overrides is awful. that's why [i described putting redundant source rules in there as harmful].

I'm suggesting you simply delete all the [constraint]s without replacement.

I'm fine with deleting constraints from Gopkg.toml, but that means etcd will need hand-maintain Gopkg.lock, which is also fine with me:

One of the sections i ended up omitting from this round of writing with the new help docs (i'd already written 15k words, and we needed to ship the release) was a "Zen of Constraints" section, that contains exactly this sort of best-practice advice. i won't be able to get to it until after FOSDEM, unfortunately, but it's the next-most-urgent set of docs to write.

Briefly, though: ideally, both etcd and cockroachdb should express the widest possible version [[constraint]] rules in their Gopkg.toml that could work. dep won't complain of a conflict then, and no overrides are needed. You then trust Gopkg.lock to keep versions the same, using dep ensure -update <project-name> to target specific dependencies for update when you want to make a change.

[gyuho]

Me and @fanminshi think this is already addressed.