On Thu, Mar 26, 2015 at 7:53 PM, Nate Finch <nate.fi...@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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
