niemeyer / gopkg

Source code for the gopkg.in service.
Other
537 stars 85 forks source link

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

Closed tve closed 11 months ago

tve commented 9 years ago

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
niemeyer commented 9 years ago

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.

tve commented 9 years ago

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.

niemeyer commented 9 years ago

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.

tve commented 9 years ago

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

niemeyer commented 9 years ago

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