go mod tidy 错误消息：“但是 go 1.16 会选择”

Question

当我运行go mod tidy几个包时显示错误

> go mod tidy

github.com/myrepo/myproj imports
    go.k6.io/k6 imports
    go.k6.io/k6/cmd imports
    github.com/fatih/color loaded from github.com/fatih/color@v1.12.0,
    but go 1.16 would select v1.13.0

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

我已经安装了 go 1.17.9。该错误的含义是什么？为什么会触发该错误？

Answer 1

此错误与Go 1.17 中引入的模块图修剪有关。

\n

在 Go 1.16 中，最小版本选择的模块图过去包含完整的模块图，而在 1.17 中，该图仅包含传递依赖项（有一些例外，请参阅上面的链接）。

\n

现在要了解触发错误的原因，您可能需要查看Go 1.17 发行说明：

\n

\n

默认情况下，go mod tidy验证与主模块相关的所选依赖项版本是否与之前的 Go 版本使用的版本相同（指定 go 1.17 的模块为 Go 1.16）[...]

\n

\n

因此，当您运行 时go mod tidy，它会报告 Go 1.16“将选择”一个传递依赖项 ( github.com/fatih/color) 的版本，该版本与 Go 1.17 的修剪图所选择的版本不同。

\n

这与构建的可重复性相关，因为包含 中指定的当前 Go 版本和前一个版本go.sum的校验和。在 Go 1.17 和 Go 1.16 中，模块图实际上可以更改，这将是不一致的。go.mod go.sum

\n

该错误消息建议进行两个修复。

\n

\n

1. go mod tidy -go=1.16 && go mod tidy -go=1.17\xe2\x80\x94 这会选择依赖版本为 Go 1.16，然后选择 Go 1.17

   \n
\n

2. go mod tidy -compat=1.17\xe2\x80\x94 这只是删除了 Go 1.16 校验和（因此提示“不需要 go 1.16 的重现性”）。

   \n
\n

\n

升级到 Go 1.18 后，该错误不应再出现，因为模块图的加载方式与 Go 1.17 中相同。

\n

Answer 2

简单说明

该错误but go 1.16 would select意味着使用 Go 1.16（或更低版本）而不是 Go 1.17（或更高版本）编译后，编译的软件（编译的二进制文件）的行为现在存在更深层次的问题。

是什么导致了这个问题呢？：这可能完全超出您的控制范围，例如，您的某个依赖项的无害更改可能会带来副作用。（正如最近看到的 和golang.org/x/oauth2类似的，它已经破坏了世界各地的许多构建。）

我可以简单地避免跑步go mod tidy吗？是的，但这对您的实际问题没有任何帮助。

那么对我来说有什么实际影响呢？到目前为止，Go 1.16 和 1.17 之间还没有构建重现性。如果您使用 Go 1.16 来构建或测试，您的程序的行为可能与 Go 1.17+ 的行为略有不同。程序的编译采用不同版本的依赖项。略有不同，但不同，而且它比底层算法的详细细节更重要。

强制构建仅与 Go 1.17（或更高版本）兼容

1. 记录/传达没有人应该使用 Go 1.16 或更低版本编译您的代码。

2. 确保您的持续集成没有使用 Go 1.16 或更低版本。

3. 在所有脚本、Makefile、管道等中，将命令更改go mod tidy为：

go mod tidy -compat=1.17

这是迁移吗？我从来没有使用过Go 1.16！

go 1.17您可能认为在您的版本中声明版本go.mod会强制使用该 Go 版本或更高版本。在这种情况下，甚至某些 Go 1.16 工具也会失败go.mod file indicates go 1.17, but maximum supported version is 1.16，这强化了这种直觉。有道理，对吧？没有。

残酷的现实是，一些此类代码库（也许你的代码库也是如此）可以使用 Go 1.16 或 Go 1.15进行编译，只要编译的模块不包含仅在更高版本的 Go 版本中添加的功能即可！核心团队不想默默地为这种人为的构建过程引入问题。这就是为什么您面临显式保留或显式放弃这种向后兼容性的决定。

替代方案：使用 Go 1.16 依赖算法

go mod tidy -go=1.16 && go mod tidy -go=1.17

将最后一个数字更改为您的最高版本，因此如果您使用的是 1.18：

go mod tidy -go=1.16 && go mod tidy -go=1.18

后一个-go=1.17（或-go=1.18）标志声明您希望将语言功能限制在 1.17（或 1.18）。

前者-go=1.16只是暂时的并立即被覆盖。那为什么需要它呢？好吧，它有一个副作用：它会在 中留下痕迹go.mod。1.17（或1.18）看到了这个标记，因此它没有使用依赖修剪的新颖算法。相反，它选择与 1.16 相同的版本并将它们保存到go.mod.