Sync Gateway 1.3 Vendoring Options

Requirements

Capture (vendor) upstream 3rd party dependency repos in case they disappear
Have the ability to point to specific commits in any dependent repos (3rd party or in-house repos)
Compatibility with standard go tooling
Compatibility with IDEs and editors (Sublime, IntelliJ, Visual Code, Emacs)

Pros

Cons

Creating + maintaining forks for all transitive dependencies is non-trivial work
Extra layer required to point to specific commits (via gopkg.in service or self-hosted server running their code, eg, deps.couchbasemobile.com/go-metrics.v1)
We'd need to maintain tags on the couchbasedeps forks -- for example if we create release 1.2.1, we'd need to tag all of the forks with that same tag.
Somewhat complicated
Easy for forks to diverge from upstream due to deadline pressure (no time to wait for upstream to merge PR so it goes directly to fork, then repos start to diverge and maybe get out of sync permanently)

Pros

All go tools work, no GOPATH mangling or submodules
Heavily used in golang community, solution will continue to improve
The tooling deals with transitive dependencies with very little manual/tedious work required
100% reproducible builds going back at any point in time
Manifest file that records state of project + deps

Cons

Editor/IDE integration not there yet, no clear idea when these will be fixed (1.6 may help)
On Go 1.5, not all of the tools fully support GO15VENDOREXPERIMENT (they are trying to fix this in 1.6)

Pros

Cons