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

Comments

@flibustenet
Copy link

commented Feb 20, 2018

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Feb 21, 2018

@rsc And is there a workaround?

@robertlestak

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2018

This issue overall is a duplicate of #24476.

@rsc rsc closed this Mar 30, 2018

@gopherbot

This comment has been minimized.

Copy link

commented Apr 18, 2018

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
cmd/go/internal/modfetch: avoid using non-canonical semver tags
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
8 participants
You can’t perform that action at this time.