x/vgo: confused by v1.1 tag in repo

[flibustenet]

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

go 1.10
vgo:2018-02-20.1

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

linux amd64

What did you do?

vgo get github.com/gorilla/securecookie
vgo build

What did you see instead?

vgo: finding github.com/gorilla/securecookie v1.1.0
vgo: github.com/gorilla/securecookie v1.1.0: unexpected status (https://api.github.com/repos/gorilla/securecookie/git/refs/tags/v1.1.0): 404 Not Found

I think

Maybe it's because securecookie has v1.1 and not v1.1.0 tag ?

[rsc]

I misread this at first. Yes, it should ignore the v1.1 tag entirely, not get confused and turn it into a v1.1.0 tag. (Semver is always three numbers, and we only allow the canonical form so that there's no ambiguity about what if v1.1 and v1.1.0 are both defined.)

[ngrilly]

@rsc And is there a workaround?

[robertlestak]

@ngrilly It's probably not a long term solution, but if you manually change the v1.1.0 to a pseudo-version in the go.mod file as defined in vgo-intro - Defining Go Modules, it will build successfully.

For example:

require (
	"github.com/gorilla/securecookie" v0.0.0-20170224193804-e59506cc896a
)

[ngrilly]

@adal-io Thanks. I ended up doing this. I think this workflow has to be improved (and documented) to maximize the adoption of vgo.

[wayt]

+1 ran into the same issue with:

• github.com/ugorji/go v1.1
• github.com/gin-gonic/gin v1.2

Using the solution from @adal-io worked.

[cryptix]

Also ran into this on a couple of packages/repos.

I tried to apply this patch but it only worked a little.

diff --git a/vendor/cmd/go/internal/semver/semver.go b/vendor/cmd/go/internal/semver/semver.go
index ecc5300..7424145 100644
--- a/vendor/cmd/go/internal/semver/semver.go
+++ b/vendor/cmd/go/internal/semver/semver.go
@@ -111,6 +111,10 @@ func Max(v, w string) string {
 }
 
 func parse(v string) (p parsed, ok bool) {
+       if v == "v1.1" || v == "v1.0" {
+               p.err = "bad bad version"
+               return
+       }
        if v == "" || v[0] != 'v' {
                p.err = "missing v prefix"
                return
diff --git a/vendor/cmd/go/internal/semver/semver_test.go b/vendor/cmd/go/internal/semver/semver_test.go
index 7a697f6..e33ddd1 100644
--- a/vendor/cmd/go/internal/semver/semver_test.go
+++ b/vendor/cmd/go/internal/semver/semver_test.go
@@ -13,6 +13,8 @@ var tests = []struct {
        in  string
        out string
 }{
+       {"v1.0", ""},
+       {"v1.1", ""},
        {"bad", ""},
        {"v1-pre", ""},
        {"v1+meta", ""},

• github.com/asaskevich/govalidator has a v0.0.1 and v1 to v9 (without .Y.Z)

All in all I must say that dealing and overwriting with (wrong) tags is quite the hurdle..

[NobbZ]

Whats the easiest way to get that date-string and the commit-SHA without cloning in advance?

And why do we actually need the date/timestamp? Why isn't the commit sha enough?

[cryptix]

And why do we actually need the date/timestamp?

I'm not sure but I think it is needed to get chronological ordering? Sorting hashes alphabetical doesn't make much sense. I also think that it is quite the strain, though and wonder why this book-keeping can't be done by the tooling itself (let it lookup the commit to get the date). I hope this will also be part of the helpers that make the release zip files, etc.

[rsc]

Whats the easiest way to get that date-string and the commit-SHA without cloning in advance?

Type a commit hash (prefix) and let vgo replace it with the v0.0.0-date-hash long form.

And why do we actually need the date/timestamp? Why isn't the commit sha enough?

To fit it into semver ordering properly.

I also think that it is quite the strain, though and wonder why this book-keeping can't be done by the tooling itself (let it lookup the commit to get the date).

It will do that if you put in a commit hash (prefix), and then it will store the full pseudo-version in the go.mod file.

To be clear, the eventual expected usage is that authors tag their releases with names like v1.2.3 and then you write that instead of specific commits. The pseudo-version is a transition mechanism / last resort. It's OK that it's ugly and inconvenient; that will only encourage using real tags instead.

[rsc]

This issue overall is a duplicate of #24476.

[gopherbot]

Change https://golang.org/cl/107659 mentions this issue: cmd/go/internal/modfetch: avoid using non-canonical semver tags