Skip to content

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

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.

Sign up for GitHub

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
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
Loading

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
Loading

@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/[email protected]: 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/[email protected]: 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/[email protected]: 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/[email protected]: 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
Loading

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
Contributor

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 <[email protected]>
@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