So it doesn't seem terrible for something that is just a copyright fix. *but* Having go get give you something very different than what we build with is just going to bite us in the future.
John =:-> On Mar 27, 2015 7:08 PM, "Eric Snow" <eric.s...@canonical.com> wrote: > 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 >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
