cmd/go: `go get module_path/v2` does not get v2 branch #33010

mholt · 2019-07-09T15:53:07Z

What version of Go are you using (`go version`)?

$ go version
go version go1.12.6 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/matt/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/matt/Dev"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sf/7w4p15_15jb59d7kwy0wglh40000gn/T/go-build886139171=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Ran go get github.com/caddyserver/caddy/v2 to make the v2 branch of the caddy module a dependency in go.mod.

What did you expect to see?

A successful go get and adding the module to go.mod.

Since v2 is a WIP, there is no v2.0.0 tag, but there is a v2 branch, which the documentation mentions is required for new major versions (either that or a v2 subfolder).

What did you see instead?

go: finding github.com/caddyserver/caddy/v2 latest
go: github.com/caddyserver/caddy/v2@v2.0.0-20190702190831-f6ee100bae9c: go.mod has non-.../v2 module path "github.com/caddyserver/caddy" (and .../v2/go.mod does not exist) at revision f6ee100bae9c
go: error loading module requirements

There is a workaround: Specifying a specific commit by appending @<sha> with a commit in the v2 branch works, e.g.: go get github.com/caddyserver/caddy/v2@902ec37

However this is not an obvious solution IMO, or at least I didn't see it documented (or documented clearly).

The text was updated successfully, but these errors were encountered:

jeanbza · 2019-07-11T00:39:40Z

https://github.com/golang/go/wiki/Modules

The go.mod file was updated to include explicit versions for your dependencies, where v1.5.2 here is a semver tag:

Modules must be semantically versioned according to semver, usually in the form v(major).(minor).(patch), such as v0.1.0, v1.2.3, or v1.5.0-rc.1. The leading v is required. If using Git, tag released commits with their versions. Public and private module repositories and proxies are becoming available (see FAQ below).

Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0.

etc

The v2 in a module definition is looking for a git tag, not a branch. The tag can live on any branch you'd like AFAIK. (it doesn't have to be called v2)

mholt · 2019-07-11T03:12:34Z

@jadekler The problem is that v2 development is not stable yet (thus untaggable), but modules being developed which require the v2 API have no way of using it.

jeanbza · 2019-07-11T03:17:57Z

Tag v2.0.0-rc1 and depend on that. :)

edit: MVS doesn't use these unless they're directly depended upon, btw. That is, if versions v2.0.0 and v2.1.0-rc1 exist, MVS will never pick the -rc1 unless specified in the go.mod.

mholt · 2019-07-11T04:18:22Z

Tag v2.0.0-rc1 and depend on that. :)

But it's not a candidate for release... tagging such would basically be dishonest. 😕

So there's no way to specify a particular branch? Why then does go get module@master (etc.) work but not version branches?

agnivade · 2019-07-11T05:05:35Z

@thepudds @bcmills @jayconrod

jayconrod · 2019-07-11T14:29:12Z

There are a couple options here. As @jadekler suggested, you can tag prerelease versions like v2.0.0-pre1. Anything after the dash is fine; you don't have to say it's a release candidate. This is probably the best approach.

In terms of go get, you can run go get github.com/caddyserver/caddy/v2@branchname except the branch can't be called v2. dev-v2 would be fine, but v2 is a special query that means "pick the newest tag with major version 2".

go help module-get gives a bit more information on what happens, but I can summarize here.

If no specific version is requested, that is there's no @master or @some-other-tag in the argument, the Go command will ask for a list of available versions for this module. It will only consider tags, not branches, unless a branch is specifically requested by name. But if the branch is named v2 or latest or something else that has a specific meaning as a query, that specific meaning wins.
When updating to the latest version (i.e., go get github.com/caddyserver/caddy/v2 or go get github.com/caddyserver/caddy/v2@latest), the Go command will pick the highest non-prerelease version with a major version that matches the module path (v2). If there is no non-prerelease version, it will consider prerelease versions. If there are no prerelease versions, it will convert the commit on the master branch to a pseudo-version like v2.0.0-20190702190831-f6ee100bae9c.
If a specific branch or tag is requested (e.g., go get github.com/caddyserver/caddy/v2@dev-v2), the Go command will see if that tag corresponds to a semantic version tag pointing to the same commit. If so, it will use that version. If not, it will generate a pseudo-version for the commit you requested.

mholt · 2019-07-11T18:59:29Z

you can tag prerelease versions like v2.0.0-pre1 ... This is probably the best approach.

Wouldn't this require tagging every commit? The goal is to always get the latest commit on a branch, just like @branchname does. I don't think it's reasonable to expect developers to tag every commit on a separate branch.

except the branch can't be called v2

If this is true, could the documentation be changed to make this very clear?

This is unfortunate, since I suppose we'd need a different branch like you suggest, v2-dev or something.

Would simply using a branch named v2-dev be a valid workaround then?

bcmills · 2019-07-11T19:08:09Z

Would simply using a branch named v2-dev be a valid workaround then?

Yes: specifically, any name for which semver.Canonical returns the empty string should work as a branch name today.

jayconrod · 2019-07-11T21:07:48Z

Wouldn't this require tagging every commit? The goal is to always get the latest commit on a branch, just like @branchname does. I don't think it's reasonable to expect developers to tag every commit on a separate branch.

That depends on your use case. Downstream users will only pick up version tags automatically. If you need users to be able to pick up every commit, then every commit should be tagged. But this is usually not the case. Developers preparing a change that requires something that hasn't been released yet can require or replace your module with the pseudo-version they need.

If this is true, could the documentation be changed to make this very clear?

Yes, we should improve that. This should be called out in go help module-get.

mholt · 2019-07-11T22:55:47Z

Thanks for the clarifications!

gopherbot · 2019-07-12T15:33:52Z

Change https://golang.org/cl/185979 mentions this issue: cmd/go: improve module version query documentation

brunetto · 2020-05-18T11:15:59Z

Would simply using a branch named v2-dev be a valid workaround then?

Hi, it doesn't seems to work for me... did it work for you?
I tried to understand this issue and the related ones but I'm not sure how to get the latest commit from a branch without tagging it every time.

If I useeither "v2-dev" or "dev-v2" I get no matching versions for query "v2".

In the go.mod file I updated the module name to v2.

jayconrod changed the title ~~mod: go get module_path/v2 does not get v2 branch~~ cmd/go: go get module_path/v2 does not get v2 branch Jul 11, 2019

jayconrod added Documentation modules NeedsFix The path to resolution is known, but the work has not been done. labels Jul 11, 2019

jayconrod self-assigned this Jul 11, 2019

jayconrod added this to the Go1.14 milestone Jul 11, 2019

gopherbot closed this as completed in 21f5484 Jul 12, 2019

bcmills mentioned this issue Jul 18, 2019

cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag or branch #29731

Open

mholt mentioned this issue Jul 23, 2019

release a v2 alpha version caddyserver/caddy#2685

Closed

mholt mentioned this issue Mar 22, 2020

Branch swap: Move master to v1, and v2 to master caddyserver/caddy#3172

Closed

rbtcollins mentioned this issue Jun 15, 2020

enh: go get of kubebuilder by tag doesn't work kubernetes-sigs/kubebuilder#1562

Closed

golang locked and limited conversation to collaborators May 18, 2021

gopherbot added the FrozenDueToAge label May 18, 2021

rsc unassigned jayconrod Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: `go get module_path/v2` does not get v2 branch #33010

cmd/go: `go get module_path/v2` does not get v2 branch #33010

mholt commented Jul 9, 2019

jeanbza commented Jul 11, 2019

mholt commented Jul 11, 2019

jeanbza commented Jul 11, 2019 •

edited

mholt commented Jul 11, 2019

agnivade commented Jul 11, 2019

jayconrod commented Jul 11, 2019

mholt commented Jul 11, 2019 •

edited

bcmills commented Jul 11, 2019

jayconrod commented Jul 11, 2019

mholt commented Jul 11, 2019

gopherbot commented Jul 12, 2019

brunetto commented May 18, 2020

cmd/go: go get module_path/v2 does not get v2 branch #33010

cmd/go: go get module_path/v2 does not get v2 branch #33010

Comments

mholt commented Jul 9, 2019

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

jeanbza commented Jul 11, 2019

mholt commented Jul 11, 2019

jeanbza commented Jul 11, 2019 • edited

mholt commented Jul 11, 2019

agnivade commented Jul 11, 2019

jayconrod commented Jul 11, 2019

mholt commented Jul 11, 2019 • edited

bcmills commented Jul 11, 2019

jayconrod commented Jul 11, 2019

mholt commented Jul 11, 2019

gopherbot commented Jul 12, 2019

brunetto commented May 18, 2020

cmd/go: `go get module_path/v2` does not get v2 branch #33010

cmd/go: `go get module_path/v2` does not get v2 branch #33010

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?

jeanbza commented Jul 11, 2019 •

edited

mholt commented Jul 11, 2019 •

edited