如何在go.mod中最好地声明golang依赖版本? [英] How to declare golang dependency versions best in go.mod?

问题描述

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

The classical way to declare a dependency's version in go mod is via

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
)

过去(执行< = 1.12吗?)已解决为时间戳版本，但是最近这些版本保持不变.

In the past (go <= 1.12 ?) this has been resolved to timestamp versions, but recently the versions are kept untouched.

但是，我也看到了这种技术 pin 版本:

However, I've also seen this technique to pin versions:

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()子句中(不仅在冲突的情况下)?

The question is why would one choose one approach over the other? Is the latter required to resolve conflicting versions coming from transitive dependencies? And if so, why shouldn't one add versions only to the replace() clause from the very beginning to be precise (not only in the conflicting case)?

推荐答案

当您要在当前模块中使用特定版本的依赖项时，替换很有用:

A replace is helpful when you want to use a particular version of a dependency in the current module:

• 您可能要使用该版本，因为它是需要修改的分支.

• You might want to use that version because it's a fork with modifications you need.

require example.com/original v1.0.0
replace example.com/original => github.com/... v1.0.1

(注意:您可以将v1.0.1替换为master(或另一个分支)，并且下次您build/test/mod tidy会将其替换为伪版本.)

(Note: you can replace v1.0.1 with master (or another branch) and it will be replaced with a pseudo-version the next time you build/test/mod tidy.)

由于某些原因，您可能无法更改此特定依赖项的次要版本.也许它需要额外的测试来验证行为，或者您尝试了较新的版本，但它们不起作用.

You may not be able to change minor versions of this particular dependency for some reason. Perhaps it requires extra testing to verify behavior or perhaps you've tried newer versions and they don't work.

您可能正在对多个项目进行更改，或者单个回购中有多个模块，并且希望能够在开发过程中同时对所有模块进行更改.

You might be making changes to multiple projects, or you have multiple modules in a single repo, and you want to be able to make changes across all of the modules at the same time while developing.

为了使替换有意义，您需要依赖依赖于要替换的模块.通过使用require在go.mod中添加依赖项，因此不能仅使用replace.

In order for a replace to be meaningful, you need to be depending on the module you are replacing. You add dependencies in a go.mod by using require, so you can't only use replace.

A replace是维护保养的额外工作，一般而言，无需更换所有东西.像上述情况一样，在必要时应有选择地使用replace.

A replace is extra work to maintain and replacing everything is not necessary in general. replace should be used selectively, when necessary, like in the situations above.

最后，添加替换不会使版本选择更加精确".添加替换使依赖项更新变得更加困难.人们最有可能需要说:是的，我们要做要升级此依赖项，"而不是让最低版本选择"决定何时升级依赖项，而这可能会在不经意的情况下意外发生.人类注意到.如上所述，这对于某些项目可能是不利的.

Finally, adding a replace does not make the version selection more "precise." Adding the replace makes it more difficult for a dependency to update. A human will most likely need to go in and say, "Yes, we do want to upgrade this dependency," rather than let Minimum Version Selection decide when to upgrade a dependency, which could happen accidentally without a human noticing. As noted above, that could be bad for some projects.

这篇关于如何在go.mod中最好地声明golang依赖版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！