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

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

Closed
flibustenet opened this issue Feb 20, 2018 · 11 comments
Closed

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

flibustenet opened this issue Feb 20, 2018 · 11 comments
Milestone

Comments

@flibustenet
Copy link

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 ?

@gopherbot gopherbot added this to the Unreleased milestone Feb 20, 2018
@rsc rsc changed the title x/vgo unexpected status with github.com/gorilla/securecookie v1.1.0 x/vgo: must use v1.1.0 tag, not v1.1 Feb 20, 2018
@rsc rsc changed the title x/vgo: must use v1.1.0 tag, not v1.1 x/vgo: confused by v1.1 tag in repo Feb 20, 2018
@rsc
Copy link
Contributor

rsc commented Feb 20, 2018

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
Copy link

ngrilly commented Feb 21, 2018

@rsc And is there a workaround?

@robertlestak
Copy link

robertlestak commented Feb 22, 2018

@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
Copy link

ngrilly commented Feb 22, 2018

@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
Copy link

wayt commented Feb 23, 2018

+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
Copy link

cryptix commented Feb 24, 2018

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
Copy link

NobbZ commented Mar 27, 2018

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
Copy link

cryptix commented Mar 28, 2018

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
Copy link
Contributor

rsc commented Mar 30, 2018

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
Copy link
Contributor

rsc commented Mar 30, 2018

This issue overall is a duplicate of #24476.

@rsc rsc closed this as completed Mar 30, 2018
@gopherbot
Copy link

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

gopherbot pushed a commit to golang/vgo that referenced this issue Apr 25, 2018
We insist that semver tags in repos be fully spelled out,
as required by semver: v1.2.0, not v1.2. In other places,
like go.mod, we do allow saying v1.2 as shorthand for v1.2.0.
Don't confuse the issue by reporting a "v1.2" tag in the
version list, since it's unaddressable. (If you type v1.2 vgo will
look for v1.2.0.)

Similarly, don't report tags that don't match the module path,
and don't report tags that look like pseudo-versions.

Additional fix for golang/go#23954, golang/go#24476.

Change-Id: Iaac0fb36362b25e5faef5271c110d432ec04bc8b
Reviewed-on: https://go-review.googlesource.com/107659
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@golang golang locked and limited conversation to collaborators Apr 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants