2 回答
TA貢獻1891條經驗 獲得超3個贊
此錯誤與Go 1.17 中引入的模塊圖形修剪有關。
在 Go 1.16 中,用于最小版本選擇的模塊圖過去包含完整的模塊圖,而在 1.17 中,該圖僅包含傳遞依賴項(有一些例外,請參見上面的鏈接)。
現在要了解是什么觸發了錯誤,您可能需要查看Go 1.17 發行說明:
默認情況下,
go mod tidy驗證與主模塊相關的所選依賴版本是否與之前的 Go 版本使用的版本相同(Go 1.16 對于指定 go 1.17 的模塊)[...]
因此,當您運行時go mod tidy,它會報告 Go 1.16“將選擇”傳遞依賴項 ( github.com/fatih/color) 的一個版本,該版本與 Go 1.17 的修剪圖所選擇的版本不同。
這與構建可重復性相關,因為go.sum包含在中指定的當前 Go 版本go.mod 和前一個版本的校驗和。在 Go 1.17 和 Go 1.16 的情況下,模塊圖實際上可以更改,go.sum這將是不一致的。
錯誤消息建議進行兩個修復。
go mod tidy -go=1.16 && go mod tidy -go=1.17— 這選擇依賴版本為 Go 1.16,然后選擇 Go 1.17go mod tidy -compat=1.17— 這只是刪除了 Go 1.16 校驗和(因此提示“不需要 go 1.16 的可再現性”)。
升級到 Go 1.18 后,錯誤不應再出現,因為模塊圖將與 Go 1.17 中一樣加載。
TA貢獻1936條經驗 獲得超7個贊
簡單說明
該錯誤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(或更高版本)兼容
記錄/傳達沒有人應該使用 Go 1.16 或更低版本編譯您的代碼。
確保您的持續集成未使用 Go 1.16 或更低版本。
在所有腳本、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 版本中添加的功能,某些此類代碼庫(也許還有您的)可以使用 Go 1.16 或 Go 1.15 進行編譯!核心團隊不想默默地為這種人為的構建過程引入問題。這就是為什么您面臨明確保留或明確放棄這種向后兼容性的決定。
備選方案:使用 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.
- 2 回答
- 0 關注
- 2418 瀏覽
添加回答
舉報
