你正在使用哪个版本的Go( go version )?
$ go version
go version go1.17.2 linux/amd64这个问题在最新版本中是否重现？
是的
你正在使用什么操作系统和处理器架构( go env )?
go env 输出
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/chris/.cache/go-build"
GOENV="/home/chris/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/chris/Code/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/chris/Code/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/chris/.local/lib/go-1.17.2"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/chris/.local/lib/go-1.17.2/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"你做了什么？
我更新了我们所依赖的一个包的版本，并运行了 go mod tidy 。
你期望看到什么？
我期望看到什么都没有，或者一个指向错误文档的错误信息。
你看到了什么？
proprietaryproject.com/internal/assets tested by
proprietaryproject.com/internal/assets.test imports
github.com/stretchr/testify/assert imports
gopkg.in/yaml.v3 loaded from gopkg.in/yaml.v3@v3.0.0-20200615113413-eeeca48fe776,
but go 1.16 would select v3.0.0-20210107192922-496545a6307b
To upgrade to the versions selected by go 1.16:
go mod tidy -go=1.16 && go mod tidy -go=1.17
If reproducibility with go 1.16 is not needed:
go mod tidy -compat=1.17
For other options, see:
https://golang.org/doc/modules/pruning我不明白问题所在，所以我按照错误信息的底部链接进行了操作： https://golang.org/doc/modules/pruning
那个链接重定向到了 https://golang.org/doc/modules/managing-dependencies ,其中没有关于这些 -compat 和 -go 标志的信息。它也没有包含 prune 这个词。
因此，我的报告实际上是一个文档错误。我对go的决定感到困惑，而且CLI指向的资源也没有帮助。那个页面的内容最近有变化吗还是其他原因？
8条答案
按热度按时间gmxoilav1#
CC @bcmills
dl5txlt92#
是的，我仍在撰写完整的文档。
dba5bblo3#
@bcmills 有没有草稿版本可以在哪里找到？
tvmytwxo4#
尚未。(我正在做的基本上是一个关于
exclude,replace和Go 1.17模块图修剪的教程。)然而，在此期间，我很乐意就具体情况提供建议。(通常如果你不确定，最简单的方法就是直接升级：
go mod tidy -go=1.16 && go mod tidy -go=1.17。)3j86kqsm5#
你好@bcmills,
我在输出中发现令人困惑的是go1.17不会升级传递依赖项，但却抱怨关于传递依赖项版本。CLI建议使用
-go=1.16,但我们已经决定不支持go1.16,而是指定go1.17。输出还表示如果不需要go1.16兼容性，可以使用-compat=go1.17,但这并不能修复go.mod,go mod tidy仍然失败。我的问题是，如果
go mod tidy -go=1.16 && go mod tidy -go=1.17在这里做对了事情，为什么我需要在不需要支持go1.16的情况下使用“go1.16模式”？是因为依赖树的某个地方有一个使用go1.16的go.mod吗？hsvhsicv6#
建议使用 -go=1.16,但我们决定通过指定 go1.17 来不支持 go1.16。
完整的建议是使用
-go=1.16,然后是-go=1.17。go mod tidy -go=1.16将选定的版本更新为 Go 1.16 会选择的内容。go mod tidy -go=1.17然后将其更改回满足 1.17 不变量，此时依赖关系应该是稳定的。(即：
go mod tidy在以这种方式升级后不应降级它们。如果不是这种情况，请提交一个单独的问题并附上重现步骤。)输出还表示，如果不需要 go1.16 兼容性，则可以使用 -compat=go1.17,但这并不能修复 go.mod,go mod tidy 仍然失败。
它不应该“修复
go.mod”，因为如果你不关心兼容性，那么它并没有什么问题。然而，如果你选择了这个选项，你需要在每个
go mod tidy中使用-compat=go1.17标志，因为-compat标志不会保留在go.mod文件中。(它存在是为了方便那些针对所有支持的 Go 版本进行测试的项目进行一次性的 1.16-to-1.17 转换，所以似乎没有必要添加一个永久性的
go.mod指令。)如果
go mod tidy -go=1.16 && go mod tidy -go=1.17在这里做对了事情，为什么我需要在使用不需要支持 go1.16 的情况下使用“go1.16 模式”？没有
-compat标志，go工具无法知道您不需要支持 Go 1.16 或更早版本上的模块消费者。然而，您确实可以通过使用
exclude指令来表示您真的不关心传递性需求：bogh5gae7#
感谢@bcmills的澄清！
如果没有-compat标志，go工具将无法知道您不需要支持模块在Go 1.16或更早版本上的消费者。
我想这就是我感到困惑的地方。我认为在
go.mod中指定go 1.17会这样做，从而消除了对-compat标志的需求。我同意在这里需要采取某种手动步骤，但我们从一个仅包含go1.17的go.mod开始，使用go1.17更新了一个依赖项，然后突然间在不先升级为go1.16的情况下，go mod tidy就无法正常工作了。r1zhe5dt8#
我遇到了相同的问题，并最终在https://go.dev/ref/mod#graph-pruning找到了相关内容。错误信息中报告的URL应该是https://go.dev/ref/mod#graph-pruning,而不是https://golang.org/doc/modules/pruning(它重定向到https://go.dev/doc/modules/managing-dependencies)。