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

Jump to bottom

cmd/go: in 'go mod init', prefer the 'version' field from Gopkg.lock instead of a pseudo-version #31251

Closed
daixiang0 opened this issue Apr 4, 2019 · 16 comments
Closed

cmd/go: in 'go mod init', prefer the 'version' field from Gopkg.lock instead of a pseudo-version #31251

daixiang0 opened this issue Apr 4, 2019 · 16 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.14

Comments

@daixiang0
Copy link

daixiang0 commented Apr 4, 2019 •
edited

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

$ go version
go version go1.12.1 linux/amd64

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/deploy/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build492195104=/tmp/go-build -gno-record-gcc-switches"

What did you do?

git clone https://github.com/cortexproject/cortex.git
go mod init
go mod vendor
go mod tidy

What did you expect to see?

I don't know why degrade.
also go mod why cannot explain.

What did you see instead?

$ grep opentracing-go go.mod 
	github.com/opentracing/opentracing-go v1.0.1
$ grep -C10 opentracing-go Gopkg.lock 
[[projects]]
  branch = "master"
  digest = "1:55a4c23a5ff747a3436588879dc6ff4ea36d2e42dad8c67449f3df4ecb4b41a7"
  name = "github.com/opentracing-contrib/go-stdlib"
  packages = ["nethttp"]
  pruneopts = "UT"
  revision = "1de4cc2120e71f745a5810488bf64b29b6d7d9f6"

[[projects]]
  digest = "1:450b7623b185031f3a456801155c8320209f75d0d4c4e633c6b1e59d44d6e392"
  name = "github.com/opentracing/opentracing-go"
  packages = [
    ".",
    "ext",
    "log",
  ]
  pruneopts = "UT"
  revision = "1949ddbfd147afd4d964a9f00b24eb291e0e7c38"
  version = "v1.0.2"
@bradfitz
Copy link
Contributor

bradfitz commented Apr 4, 2019

I don't understand the bug report.

I don't know why degrade.

What is "degrade"? Is that a module name? Or a verb? How's it being degraded?

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 4, 2019
@daixiang0
Copy link
Author

@bradfitz you may see github.com/opentracing/opentracing-go part in my issue info, that is degraded from "v1.0.2" to "v1.0.1".

@bradfitz bradfitz added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 4, 2019
@bradfitz bradfitz changed the title cmd/go: why module degrade dependence cmd/go: go mod downgrades dependency version Apr 4, 2019
@bradfitz
Copy link
Contributor

bradfitz commented Apr 4, 2019

/cc @bcmills

@daixiang0
Copy link
Author

@bcmills hi, any input?

@bcmills
Copy link
Contributor

bcmills commented Apr 8, 2019

@daixiang0, I'm not able to reproduce the observed downgrade using go 1.12.1. Please attach exact steps to reproduce the problem, starting from a clean copy of the repository.


cortex$ go1.12.1 mod init
go: creating new go.mod: module github.com/cortexproject/cortex
go: copying requirements from Gopkg.lock

cortex$ go1.12.1 mod vendor

cortex$ go1.12.1 mod tidy
go: finding github.com/kylelemons/godebug/pretty latest
go: finding github.com/bmizerany/assert latest
go: finding github.com/kylelemons/godebug latest
go: finding github.com/google/martian/fifo latest
go: finding github.com/google/martian/martianlog latest
go: finding github.com/google/martian/httpspec latest
go: finding github.com/google/martian/mitm latest
go: finding github.com/cznic/ql/driver latest
go: finding github.com/bitly/go-hostpool latest

cortex$ go1.12.1 list -m github.com/opentracing/opentracing-go
github.com/opentracing/opentracing-go v1.0.2

cortex$ grep opentracing-go go.mod
        github.com/opentracing/opentracing-go v1.0.2

cortex$

@bcmills bcmills added modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 8, 2019
@bcmills bcmills added this to the Go1.13 milestone Apr 8, 2019
@daixiang0
Copy link
Author

daixiang0 commented Apr 9, 2019 •
edited

@bcmills i remove old repo and git clone a new on, can reproduce it.

```
# GO111MODULE=on go mod init
go: creating new go.mod: module github.com/cortexproject/cortex
go: copying requirements from Gopkg.lock
go: converting Gopkg.lock: stat k8s.io/client-go@a47917edff34c2c3f7be36398e3ebad6011ce05c: unrecognized import path "k8s.io/client-go" (https fetch: Get https://k8s.io/client-go?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat sigs.k8s.io/yaml@v1.1.0: unrecognized import path "sigs.k8s.io/yaml" (https fetch: Get https://sigs.k8s.io/yaml?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/apimachinery@2b1284ed4c93a43499e781493253e2ac5959c4fd: unrecognized import path "k8s.io/apimachinery" (https fetch: Get https://k8s.io/apimachinery?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/klog@v0.2.0: unrecognized import path "k8s.io/klog" (https fetch: Get https://k8s.io/klog?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/api@05914d821849570fba9eacfb29466f2d8d3cd229: unrecognized import path "k8s.io/api" (https fetch: Get https://k8s.io/api?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
# grep opentracing-go go.mod
	github.com/opentracing/opentracing-go v0.0.0-20170426175816-1949ddbfd147
# GO111MODULE=on go mod vendor
# grep opentracing-go go.mod
	github.com/opentracing/opentracing-go v1.0.1
# GO111MODULE=on go mod tidy
go: finding github.com/kylelemons/godebug/pretty latest
go: finding github.com/kylelemons/godebug latest
go: finding github.com/bmizerany/assert latest
go: finding github.com/bitly/go-hostpool latest
go: finding github.com/google/martian/martianlog latest
go: finding github.com/google/martian/fifo latest
go: finding github.com/google/martian/mitm latest
go: finding github.com/google/martian/httpspec latest
go: finding github.com/cznic/ql/driver latest
[root@dx-app2 cortex]# grep opentracing-go go.mod
	github.com/opentracing/opentracing-go v1.0.1
[root@dx-app2 cortex]# GO111MODULE=on go list -m github.com/opentracing/opentracing-go
github.com/opentracing/opentracing-go v1.0.1
```
Is that my network issue? seems those timeout repos do not relate to `opentracing-go`.

In case my env not clean, i start a golang container to test

```
# docker run -it golang:1.12.1 /bin/bash
root@3d96f367c88e:/go# go get github.com/cortexproject/cortex
package github.com/cortexproject/cortex: no Go files in /go/src/github.com/cortexproject/cortex
root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# /go/src/github.com/cortexproject/cortex
root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# export GO111MODULE=on  
root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# go mod init
go: creating new go.mod: module github.com/cortexproject/cortex
go: copying requirements from Gopkg.lock
go: converting Gopkg.lock: stat k8s.io/apimachinery@2b1284ed4c93a43499e781493253e2ac5959c4fd: unrecognized import path "k8s.io/apimachinery" (https fetch: Get https://k8s.io/apimachinery?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/client-go@a47917edff34c2c3f7be36398e3ebad6011ce05c: unrecognized import path "k8s.io/client-go" (https fetch: Get https://k8s.io/client-go?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat sigs.k8s.io/yaml@v1.1.0: unrecognized import path "sigs.k8s.io/yaml" (https fetch: Get https://sigs.k8s.io/yaml?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/klog@v0.2.0: unrecognized import path "k8s.io/klog" (https fetch: Get https://k8s.io/klog?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
go: converting Gopkg.lock: stat k8s.io/api@05914d821849570fba9eacfb29466f2d8d3cd229: unrecognized import path "k8s.io/api" (https fetch: Get https://k8s.io/api?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)
root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# grep opentracing-go go.mod
	github.com/opentracing/opentracing-go v1.0.2
root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# go mod vendor
go: finding github.com/bradfitz/gomemcache v0.0.0-20170208213004-1952afaa557d
go: finding github.com/mattn/go-isatty v0.0.2
go: finding github.com/go-kit/kit v0.5.0

root@3d96f367c88e:/go/src/github.com/cortexproject/cortex# grep opentracing-go go.mod

github.com/opentracing/opentracing-go v1.0.2

Seems that my env is not clean then get this unexpected error?

hi, @bcmills how can i check my env is clean or not? and, why tag with go 1.13?

@daixiang0
Copy link
Author

daixiang0 commented Apr 10, 2019 •
edited

Hi, @bcmills , i run test in container:

Hi, i do below test in clean env:

$ docker run golang:1.12.1 /bin/bash
# go get github.com/cortexproject/cortex
# cd /go/src/github.com/cortexproject/cortex
# export GO111MODULE=on
# go mod init
# go mod vendor
# go mod tidy

the version of opentracing-go is v1.0.2, so does it mean my env not clean? If so, how can i ensure my env clean?

@daixiang0
Copy link
Author

hi, @bcmills any update?

@bcmills
Copy link
Contributor

bcmills commented Apr 11, 2019 

  github.com/opentracing/opentracing-go v0.0.0-20170426175816-1949ddbfd147

That's the trouble. Somewhere in your module cache, you have an entry for commit 1949ddbfd147 with a pseudo-version beginning with v0.0.0 instead of the current v1.0.2 tag for that commit.

Avoiding the creation of such invalid entries is #27171.

However, in this case there is a bit more: given that your Gopkg.lock specifies the correct version tag, we should know to try that version tag even if there is an existing cache entry for the commit hash with a different version. I'll retitle the issue accordingly, and thanks for the report.

@bcmills
Copy link
Contributor

bcmills commented Apr 11, 2019

(CC @jayconrod)

@bcmills bcmills changed the title cmd/go: go mod downgrades dependency version cmd/go: in 'go mod init', prefer the 'version' field from Gopkg.lock instead of a pseudo-version Apr 11, 2019
@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 11, 2019
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 11, 2019
@daixiang0 daixiang0 mentioned this issue May 6, 2019
Merged
5 tasks
@daixiang0

This comment has been minimized.

Sign in to view
@bcmills

This comment has been minimized.

Sign in to view
@daixiang0

This comment has been minimized.

Sign in to view
@gopherbot
Copy link

Change https://golang.org/cl/178497 mentions this issue: cmd/go: use the rev to resolve tags for pseudo-versions in mod init

gopherbot pushed a commit that referenced this issue May 31, 2019
@cuonglm
cmd/go: use the rev to resolve tags for pseudo-versions in mod init
9e31b17 
Fixes #32161
Updates #31251

Change-Id: I22760836b48cd734b90bc43aacb23e23e38c0f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/178497
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@bcmills
Copy link
Contributor

bcmills commented Sep 18, 2019

The fix for #33767 seems like it will also be the right general fix for this issue: instead of directly querying the modfetch package to resolve the commit to a version, we should use the modload.Query path, which already makes a best-effort attempt to convert commit hashes to canonical semantic versions.

@bcmills
Copy link
Contributor

bcmills commented Sep 18, 2019

Duplicate of #33767

@bcmills bcmills marked this as a duplicate of #33767 Sep 18, 2019
@bcmills bcmills closed this as completed Sep 18, 2019
@golang golang locked and limited conversation to collaborators Sep 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
5 participants
@bradfitz @andybons @bcmills @gopherbot @daixiang0