我们应该为用户提供一种方法，防止 go get -u 更新某些依赖项，除非它们被明确请求。
用户可能需要将模块依赖项固定到较低版本的几个原因。例如：
- 依赖项具有破坏性更改，这是允许在
v0版本中发生的。 - 存在涉及主模块的循环依赖关系，必须小心处理以保持特定版本的循环。这在其中一个模块是另一个的前缀时尤其重要，因为我们希望避免在包之间移动时出现模糊的导入。
- 依赖项添加了许多不需要的额外传递依赖项，这些依赖项可能需要下载。
- 依赖项具有新功能，但未使用，并增加了显著的开销。
当用户有一个需要特别注意更新的依赖项时，go get -u单独使用是不安全的。相反，需要构建一个包含所有需求的列表，排除不应该更新的模块，然后将该列表传递给go get -u。这很繁琐。
一些改进的想法：
- 一个
-except或-exclude标志，允许用户指定不应更新的模块。 - 在
go.mod中的注解或注解，告诉go get -u除非在命令行上明确命名，否则不要更新模块。
这与 #28424 有一定的关联。
9条答案
按热度按时间ugmeyewa1#
在
go.mod文件中的exclude指令让我们部分实现了目标：如果出现了一些回归问题，例如大量的新依赖项或显著的性能下降，那么维护者应该修复这些回归并发布一个新版本，或者用户应该分叉该模块以移除不必要的膨胀。无论如何，需要暂停的时间都只应该是一两个版本。unguejic2#
我们可能需要以其他方式解决循环依赖问题，例如让
go get -u检测到循环并尝试升级过去( #27899 )。特别是，我们不能阻止给定模块的外部用户引入更新的需求，因此依赖于某个较旧版本似乎很脆弱。qqrboqgw3#
最后，如果在
v0版本中出现了破坏性的变化，那么最好还是提醒修复调用站点。(作为解决方法，你可以始终将特定模块的明确较旧版本传递给go get -u,并在更新命令中包含该明确信息是一个很好的指标，表明你的模块正面临着悬在头顶的达摩克利斯之剑兼容性问题...)dl5txlt94#
我无法准确判断这些问题的严重程度或出现频率。正如你所指出的，对于所有这些问题，都有替代方案，但我不确定它们会经常出现，或者它们会有多烦人。
让我们将此标记为未计划，并在模块默认启用后决定如何处理。我认为在那之前，这不是一个关键功能。
k7fdbhmy5#
我认为这个用例最适合的查询方式是特殊版本查询。
upgrade已经表示“当前选定的版本或更高”，而patch表示“当前选定的版本或更高，但在同一次修订版中”；这些逻辑的后续步骤可能是某个第三标记(也许是current?),表示“当前选定的版本且没有更高的”。jaxagkaj6#
这种可能性有多大？我现在处于一个场景中，我想更新我的
go.mod中的所有依赖项，除了一个由于我们尚未准备好采用的破坏性更改。实际上，我希望将此依赖项固定在我们当前的版本上，同时仍然允许其他所有内容进行更新。我今天无法找到正确完成此操作的方法。vptzau2j7#
@braydonk,今天你可以将你想要保留的包或模块的版本作为显式参数传递给
go get -u,例如：vmdwslir8#
啊，酷，当我在查看文档或甚至博客文章时，我无法在那里找到它。谢谢你的技巧！
rpppsulh9#
我也非常希望看到这个功能。在我正在工作的代码库中，我们有3个特定的依赖项，它们引入了破坏性的更改，因此无法进行更新。我非常希望能够做类似
go get -pin example.com/foo@v0.5的事情，即在go.mod中的相关行后添加一个// pinned注解，以便后续的go get -u ./...执行跳过固定模块。