gopkg icon indicating copy to clipboard operation
gopkg copied to clipboard

gopkg.in prefers 'go1' branch over 'v1.0.9' branch?

Open tve opened this issue 9 years ago • 5 comments

It appears that gopkg.in prefers the go1 branch over a properly versioned branch? This seems like a bug to me. One specific reason for which I want a go1 branch is to force users to use the gopkg.in imports for master without having custom import comments in the master branch itself (which is impractical for development).

I created a test repo: https://github.com/rightscale/gopkgintest which has master, go1 and v1.0.9 branches. They all have slightly different simple.go to make them easy to identify. Here's what I get:

$ cd /tmp
tve@h:/tmp$ mkdir -p go/src
tve@h:/tmp$ cd go/src
tve@h:/tmp/go/src$ export GOPATH=/tmp/go
tve@h:/tmp/go/src$ go get -v gopkg.in/rightscale/gopkgintest.v1
Fetching https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
Parsing meta tags from https://gopkg.in/rightscale/gopkgintest.v1?go-get=1 (status code 200)
get "gopkg.in/rightscale/gopkgintest.v1": found meta tag main.metaImport{Prefix:"gopkg.in/rightscale/gopkgintest.v1", VCS:"git", RepoRoot:"https://gopkg.in/rightscale/gopkgintest.v1"} at https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
gopkg.in/rightscale/gopkgintest.v1 (download)
gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src$ cd gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ git status
HEAD detached at origin/go1
nothing to commit, working directory clean
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ cat simple.go
package gopkgintest

func branch() string { return "go1" }
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ go version
go version go1.4 linux/amd64

tve avatar May 27 '15 19:05 tve

This is beyond the control of gopkg.in, as it's the "go" tool that is switching over the branch content after it acquires it. That said, it's still not clear to me why you'd want that go1 branch. You might even drop the master branch altogether if you wish, and both the git and the go tool workflow would still work fine. In github you may easily modify what is the focus of development at the moment, and everything else (PRs, Issues, etc) will work in terms of it. Another trick you may use is to create a master branch which errors out nicely if imported.

Have a look at https://github.com/go-mgo/mgo for example, to see some of these ideas in use.

niemeyer avatar May 27 '15 19:05 niemeyer

How does gopkg.in tell go get which branch to checkout? Is that by setting the default branch?

We like using master as the dev branch because all our 300+ repos do that. I thought that a go get github.com/... would check out the go1 branch while going via gopkg.in wouldn't so I wanted to break the go1 branch to catch mistakes where someone (like myself...) imports the github version by mistake.

tve avatar May 27 '15 19:05 tve

When you checkout a branch with git, the references in that branch are retrieved as well, so the go tool can trivially switch over to that when it finds the reference available. Also, you can certainly continue to use master as your development target, if that's what you'd like to do inside your GitHub workflow.

We can also disable the go1 tag when going via gopkg.in, as that's clearly getting in the way and doing no good, but for the time being (before that feature is released) I suggest just dropping the tag.

niemeyer avatar May 27 '15 20:05 niemeyer

Understood. BTW, thanks for gopkg.in !!!

tve avatar May 27 '15 22:05 tve

You're welcome, and glad it's being useful there.

niemeyer avatar May 27 '15 22:05 niemeyer