0

I am trying to have a local copy of current code base of mgo.v2. https://gopkg.in/mgo.v2 says to install using go get gopkg.in/mgo.v2. I forked it from https://github.com/go-mgo/mgo/tree/v2 and trying to install it from go get forked repo from git but it changes the package structure(changes from /src/gopkg.in --> /src/github.com) and it fails saying

src/github.com/eateshk/mgo.v2/error.go:4: "ERROR: the correct import path is gopkg.in/mgo.v2 ... " evaluated but not used

I understand the error, but what's the solution for this ?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
timedout
  • 541
  • 1
  • 4
  • 12
  • What do you mean it changes the package structure? Please show an example of your problem. – JimB Nov 09 '15 at 14:24
  • Directory structure changes from /src/gopkg.in --> /src/github.com, added it in description. Thanks. – timedout Nov 09 '15 at 14:34
  • How are you "trying to install it from go get forked repo from git"? What commands did you invoke? – mrd0ll4r Nov 09 '15 at 14:39
  • If you understand the error, why not just fix the directory name? – JimB Nov 09 '15 at 14:43
  • I simply forked it from https://github.com/go-mgo/mgo/tree/v2, then ran **go get github.com/path/to/repo** – timedout Nov 09 '15 at 14:44
  • @JimB I can try that way, although not sure if it'll work. But just want to know if we have some solutions which work more cleanly for vendoring such libraries. – timedout Nov 09 '15 at 14:46
  • You not sure if what will work? The only difference is the directory name. If you `go get gopkg.in/mgo.v2` you'll have the same code in the correct directory names, or you can change the names of the directories manually. – JimB Nov 09 '15 at 14:57
  • @JimB - Tried that, but with go get github.com/path/to/repo, it doesn't download anything but one error.go file and fails with error I've listed in question description. – timedout Nov 09 '15 at 15:16
  • You're on in the wrong branch, checkout `v2`, and make sure the import path is still `gopkg.in/mgo.v2` – JimB Nov 09 '15 at 15:26

1 Answers1

1

This is a common problem when forking go packages. Canonical or "vanity" imports require the code to live in the specified path or they won't compile. The only solution is to remove the // import "gopkg.in/whatever" comment that exists somewhere.

There are other problems with your approach as well. imports within their repository will resolve back to the original repo and cause all kinds of confusion unless you rewrite them.

Rather, I suggest an alternate approach. The only place this can live on disk without causing problems is $GOPATH/src/gopkg.in/mgo.v2. Anything else will cause problems. So:

go get gopkg.in/mgo.v2
cd $GOPATH/src/gopkg.in/mgo.v2
git remote add mine your_git_fork

Now you can pull upstream changes from origin and push your changes to mine. It feels a bit odd, but it really is the only way to work from a fork without causing tons of extra pain by rewriting things.

captncraig
  • 22,118
  • 17
  • 108
  • 151