go module dependency changed back atomatically, which i don't want

[winjeg]

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

$ go version
go version go1.13.1 windows/amd64

Does this issue reproduce with the latest release?

1.13.1 YES

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

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\winjeg\AppData\Local\go-build
set GOENV=C:\Users\winjeg\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\software\gosrc
set GOPRIVATE=
set GOPROXY=https://goproxy.io,direct
set GOROOT=D:\software\goinst
set GOSUMDB=off
set GOTMPDIR=
set GOTOOLDIR=D:\software\goinst\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\projects\go\Devops\ops-base\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\winjeg\AppData\Local\Temp\go-build496850154=/tmp/go-build -gno-record-gcc-switche

What did you do?

Programmer

What did you expect to see?

when I change back to a lower version, using go get, it should not change back to the former version.

What did you see instead?

every time i try to run or bulid my program, the version of the dependency go-commons changed back, no matter how hard i tried.
I tried to clean up the gopath files as well.

[bcmills]

Duplicate of #33284

[bcmills]

Some transitive dependency in your module graph already requires the higher version. go mod graph can show you which one, and you can examine the output of go mod graph to find the path from your module to that requirement.

[winjeg]

Some transitive dependency in your module graph already requires the higher version. go mod graph can show you which one, and you can examine the output of go mod graph to find the path from your module to that requirement.

1. I tried to downgrade the version of the go-commons package, it seemed ok.
2. I tried go mod graph | grep go-commons, it show no other dependency require a higher version of the package go-commons
3. I tried to run go build ., the dependency just changed again.

A little help here, thanks.

ps: can go build show which dependcy is changed and why it is changed with exra args added ?

@bcmills

[bcmills]

That probably means that the go command upgraded the module in order to provide some missing package for an import statement.

In that case, go mod why -m github.com/winjeg/go-commons may be able to tell you where that import statement is, or else try Go 1.14 beta 1 (which logs to stderr whenever it upgrades a dependency in order to satisfy an import).

[bcmills]

Actually, in your animation there is an error message that seems to describe the problem. Please attach failure messages and other relevant data as text rather than (especially animated!) images.

[winjeg]

It't another project and the same result.
here is the whole thing... even go mod why can change the dependency back

the output is somewhat strange, the issue below mentioned the same.
#31351

I'll try to find a way to write down more detailed steps to reproduce the problem

[winjeg]

Here is a demo project to prove it.

mkdir demo
cd demo 
go mod init demo
touch main.go
go get github.com/winjeg/go-commons  # which will get the latest version 1.2.1

then you paste the following code into main.go

package main

import (
	"fmt"
	"github.com/winjeg/go-commons/uid"
)

func main() {
	fmt.Println(uid.UUIDShort())
}

then just run it use go run main.go
then you go back and get the older version @v0.0.1

go get -u github.com/winjeg/go-commons@v0.0.1

then you should notice the content of go.mod is already changed

and then you try go mod why -m github.com/winjeg/go-commons, you will get the follwing output

D:\projects\go\demo>go mod why -m github.com/winjeg/go-commons                                                          # github.com/winjeg/go-commons                                                                                          (main module does not need module github.com/winjeg/go-commons) 

go back and watch the file go.mod, the file changed back to version 1.2.1 automatically

here is the complete steps

ps:
I also want to know why getting back the older version caused so many indrect dendencies, the code is completely the same of the two different versions.

[bcmills]

Well here's your trouble. You apparently moved the v0.0.1 tag.

Modules are (intentionally) immutable: the same version must always refer to the same bytes, forever, starting from when that version is first published.

With the default GOPROXY value, downloading v0.0.1 gives you the copy of that version that was initially published, which does not include the github.com/winjeg/go-commons/uid package. When you run go build, go mod tidy, or any other command that needs to load that package, the go command upgrades you to a version that includes that package — and the only released version that includes it is v1.2.1.

demo$ GOPROXY=direct go1.14beta1 mod download
github.com/winjeg/go-commons@v0.0.1: verifying module: checksum mismatch
        downloaded: h1:z3edKP8Wq4tBAqxAbyJRBIAj4gVfOrmDop4Jt+aJYuE=
        sum.golang.org: h1:TlzoXb4plQwNaXXrYOjIFmij1pyC+l3f5snK8bMbmJI=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

demo$ GOPROXY='' go1.14beta1 mod download

demo$ go list github.com/winjeg/go-commons/...
github.com/winjeg/go-commons/conf
github.com/winjeg/go-commons/httpclient
github.com/winjeg/go-commons/log
github.com/winjeg/go-commons/str

As far as I can tell, this is all working as designed. Module versions are immutable — don't expect to mutate them.

[winjeg]

First many thanks.

---

At fist I thought the version is directly related to the tags that is tagged on the project.

So, you cannot do a re-version unless you change the module name ?
What if the version you release is not good, or not released intensionally?
I encountered the same problem with go-grpc, I also cannot downgrade to a lower version.
Can there be any workarounds except changing the modlue name ?

[bcmills]

If there is a problem with a released version, then you can issue a patch release to fix the problem and upgrade to that.

In some cases it may take a fair amount of work to upgrade a bad dependency completely away, but we're working on improving those cases in the future; see #34189, #24031, and related issues.