Ok, so, first and foremost, the last part of the import path and the
package name are not *required* to be the same. They are strongly
suggested to be the same, but they are in fact completely independent. The
import path is simply the path on disk inside your $GOPATH/src. Only "go
get" translates this into a URL. Go build etc just expect it to be a path
on disk, so you can have
import "foo/bar"
and as long as there's go code at $GOPATH/src/foo/bar, go build will work
fine.
Now the package name is whatever you put in the statement at the top of
each file
package "zzzz"
You can put that package statement inside a go file in the aforementioned
foo/bar path, and that'll work just fine. The code would look something
like this:
import "foo/bar"
var a = zzzz.Something
The reason it is suggested that you make the package name and the last part
of the import path the same is just to make developers lives easier, so
it's more obvious what the package name is and what import path it comes
from.
So... given all this, the import path
import "gopkg.in/foo/bar.v2"
Again, this just points to a path on disk to the go build tool. If you
have a folder $GOPATH/src/gopkg.in/foo/bar.v2 ... the build tool will look
for code in that folder. As for go get, it expects that to be a URL... and
indeed, the gopkg.in website will serve up a URL at that path, with
metadata that tells the go tool where to download the source code from.
gopkg.in does a little git magic redirection to translate the git clone
request from
https://gopkg.in/foo/bar.v2 to git://github.com/foo/bar (v2
branch). I'm not a git expert, so I can't comment on how exactly that code
works, but, it does.
And, as before, the package name is whatever is declared in the code inside
that folder. Most likely, the package name for this code would be "bar",
but in theory it could be anything.
I hope that helps.
