Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mholt opened this issue Jul 9, 2019 · 11 comments

Comments

Projects
None yet
6 participants
@mholt
Copy link

commented Jul 9, 2019

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).

@jadekler

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

@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.

@jadekler

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

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.

@jayconrod 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

@mholt

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

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.

@jayconrod jayconrod self-assigned this Jul 11, 2019

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

@mholt

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

Thanks for the clarifications!

@gopherbot

This comment has been minimized.

Copy link

commented Jul 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.