gpt4 book ai didi

go - 如何在 go.mod 中最好地声明 golang 依赖版本?

转载 作者:行者123 更新时间:2023-12-01 21:13:42 24 4
gpt4 key购买 nike

在 go mod 中声明依赖版本的经典方法是通过

require (
k8s.io/api v0.17.4
k8s.io/apimachinery v0.17.4
k8s.io/cli-runtime v0.17.0
k8s.io/client-go v0.17.4
)

过去(go <= 1.12 ?)这已解决为时间戳版本,但最近版本保持不变。

但是,我也有 seen这种技术固定版本:

require (
k8s.io/api v0.17.4
k8s.io/apimachinery v0.17.4
k8s.io/client-go v11.0.1-0.20190805182717-6502b5e7b1b5+incompatible
k8s.io/code-generator v0.18.0
k8s.io/kube-openapi v0.0.0-20191107075043-30be4d16710a
)

replace (
k8s.io/api => k8s.io/api v0.16.4
k8s.io/client-go => k8s.io/client-go v0.16.4
k8s.io/code-generator => k8s.io/code-generator v0.16.4
k8s.io/kube-openapi => k8s.io/kube-openapi v0.0.0-20190816220812-743ec37842bf
)

问题是为什么有人会选择一种方法而不是另一种方法?后者是否需要解决来自传递依赖的冲突版本?如果是这样,为什么不应该只将版本添加到 replace()从一开始就准确的条款(不仅在冲突的情况下)?

最佳答案

当您想在当前模块中使用特定版本的依赖项时,替换很有帮助:

  • 您可能想要使用该版本,因为它是一个带有您需要的修改的分支。
    require example.com/original v1.0.0
    replace example.com/original => github.com/... v1.0.1

    (注意:您可以将 v1.0.1 替换为 master(或其他分支),下次您 build/test/mod tidy 时,它将被替换为伪版本。)
  • 由于某种原因,您可能无法更改此特定依赖项的次要版本。也许它需要额外的测试来验证行为,或者您可能已经尝试过较新的版本并且它们不起作用。
  • 您可能正在对多个项目进行更改,或者您在一个存储库中有多个模块,并且您希望能够在开发时同时对所有模块进行更改。

  • 为了使替换有意义,您需要取决于要替换的模块。您在 go.mod 中添加依赖项通过使用 require , 所以你不能只使用 replace .

    一个 replace通常不需要额外的工作来维护和更换所有东西。 replace必要时应有选择地使用,如上述情况。

    最后,添加替换不会使版本选择更加“精确”。添加替换会使依赖项更难更新。一个人很可能需要进去说,“是的,我们确实想升级这个依赖项”,而不是让最小版本选择决定何时升级一个依赖项,这可能会在没有人注意的情况下意外发生。如上所述,这可能对某些项目不利。

    关于go - 如何在 go.mod 中最好地声明 golang 依赖版本?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62005883/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com