backporting changes to packages that use gopkg.in

[Eric Snow]

On Thu, Mar 26, 2015 at 7:53 PM, Nate Finch <nate.finch at canonical.com> wrote:
> tl;dr: godeps overrides gopkg.in, so you can have godeps pin a commit from a
> different branch than gopkg.in is retrieving (i.e. make a release-number
> branch, like "1.22" and use godeps to pin commits from there, even if go get
> & gopkg.in is getting a different branch).

So basically, gopkg.in is just a means for a project to explicitly
control, in a sane way, the git revision that `go get` uses.  If your
project does *not* use something like gopkg.in then either tip of the
master branch must always be correct (messy) or folks that import your
code must manually manage the revision (as we do with godeps).

There is a lot less magic going on with gopkg.in than you might think.
In the context of `go get`, gopkg.in just proxies the github URL to
the corresponding named revision (branch or tag).  It does not cache a
copy of the branch or repo or otherwise restrict the revisions
available to the git fetch that `go get` does.  So non-ancestor
revisions still get downloaded.  That's why could still take the
godeps/"1.22"-branch approach without a lot of complexity.

In the context of juju core, using gopkg.in for dependencies doesn't
buy us as much since we use godeps.  It's still fine though since the
import "URL" indicates the intended target and it doesn't impede our
ability to adjust via godeps (as I originally thought it did).

-eric