英文:
understanding "go mod vendor"
问题
"go mod vendor"命令的目的是什么？我以为使用vendoring后，包将不会存储在模块缓存中。然而，如果我理解正确的话，我认为这是不正确的，因为我们需要先通过"go mod tidy"或"go get"更新go.mod，然后再执行"go mod vendor"。看起来"go mod tidy"和"go get"会下载模块缓存中的包。对我来说，"go mod vendor"似乎是模块缓存的一个副本。为什么我们需要在项目的根目录中有一个模块缓存的副本呢？
还有一个问题：设置我们的环境的推荐方式是什么？假设我正在使用GOPROXY和GOPRIVATE。使用哪个更好？vendor目录还是模块缓存？或者两者都可以？
我已经阅读了这篇文章。
谢谢！
英文:
What is the purpose of "go mod vendor". I thought with vendoring packages will not be stored in module cache. However, if I understand correctly, I think this is not correct since we need to update go.mod first before "go mod vendor" by either "go mod tidy" or "go get". It seems "go mod tidy" and "go get" download packages in module cache. To me, "go mod vendor" seems like a copy of module cache. Why do we need a copy of module cache in our project's root directory?
One more question: What is the recommended way for setting up our environment? Let's say I am using GOPROXY and GOPRIVATE. Which one is better to use? vendor directory or module cache? or it does not matter.
I have already read this post.
Thanks!
答案1
得分: 2
作为程序员，我们最主要的痛点始终是缺乏控制。依赖关系是一个棘手的问题，你不能在纯软件中构建任何东西，而不依赖于已经存在的东西。不仅是硬件，通常还包括操作系统及其驱动程序，以及可能的外部库。
外部库就是 Go 模块的用武之地。你可以使用 go mod tidy 和 go get 从互联网上下载依赖项，如果你的计算机上没有它们的话。
一旦你拥有了这些库，你可以使用 go mod vendor 将它们从系统的 Go 缓存目录复制到实际使用它们的代码库中。你可以将这些依赖项提交到源代码控制中。这样，你对所依赖的代码拥有完全的控制权。这些依赖项现在是你代码的一部分，你现在拥有它们。即使你没有将它们放入 vendor 目录，你仍然拥有它们，但你对它们缺乏控制，这是一个应该避免的情况，如果你希望你的代码具有未来的兼容性。
一旦你的代码及其所有的库依赖项都被放入 vendor 目录并上传到 GitLab（例如），那么无论你所依赖的库的原始所有者是否从 GitLab 中移除他们的库，都不会有任何影响。你现在可以从你的清单中删除一个潜在的问题。这就是为什么使用 vendor 目录是有意义的原因。
英文:
As programmers, our main pain point is always lack of control. Dependencies are a tricky thing, you cannot built anything in pure software, without depending on something that already exists. Not only the hardware, but typically the OS and its drivers, and potentially external libraries.
External libraries is where Go modules come in. You use go mod tidy and go get to download dependencies from the internet when you do not already have them on your computer.
Once you have the libraries, you can use go mod vendor to copy them from your system's Go cache directory to the actual repository that uses them. You check in these dependencies into source control. This way you have total control over the code you depend upon. These dependencies are now part of your code, you own them now. You actually own them, even if you do not vendor them, but you lack control over them, which is a situation that is to be avoided if you like your code future-proof.
Once you have your code with all its library dependencies vendored and uploaded to GitLab (for example), it does not matter whether the original owner of a library you depend upon pulls the rug from under you and removes their library from GitLab, for example. You now have one potential problem erased from your list. That is the reason why vendoring makes sense.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论