Go: 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