Vendoring 一直是 Go 社区最近的热门话题。这部分是因为即将发布的 1.5 版本将 在工具链中内置一些用于供应商的辅助功能 。有时似乎有这样一种观点，即处理包依赖性的方法始终是 vendor。但是，真的是这样吗？
<要成为一个成熟的生态系统，您需要支持做和不做供应商的项目。
什么是销售？
包销售通常指的是依赖包与项目存储在同一位置的情况。这通常意味着您的依赖项已签入源代码管理系统，例如 Git。这是常见的情况，也是这篇文章如何处理这个主题的。
不卖东西的人
我将从那些不供应商的人的故事开始，因为这是我参与过的 Go 讨论中较少提及的一个。许多项目甚至生态系统通常不供应商项目，并且工具支持这一点.我将用两个例子来说明。
首先，看看
node.js
开发人员。每个人都使用
npm
来管理依赖项。在
package.json
文件中指定了包及其版本。任何开发人员都可以获得该项目，运行
npm install
并拥有一个安装了所有依赖项的可靠环境。
像
Travis CI
这样的工具有额外的支持来帮助解决这个问题。默认情况下，Travis CI 会在
node_js
项目上为你运行
npm install
。 Travis CI 还提供了您可以利用的缓存功能。这可用于缓存依赖项，因此您不必每次都去 Internet 获取它们。
其次，看 OpenStack 项目。这是一个云平台。这是一个包含许多子项目的项目，这些子项目使用共享项目来相互操作。由于空间的性质，它很复杂。它有自己的 CI/CD 系统，并使用镜像将依赖项的副本保留在靠近执行环境的位置。想象一下出售所有交叉依赖项？
这些情况很常见，其他生态系统使它们能够发生。
无论您查看 TIOBE 索引 还是 来自 Red Monk 的报告 之一，Not vendoring 都是常见的或默认的许多最流行的语言。
但是，Go 项目呢？有工具链来支持那些不供应商的人。这包括 Cloud Foundry 和 Heroku 的构建包、包管理器等。
许多 Go 项目今天没有供应商，许多将继续不依赖于供应商。特别是如果生态系统让它变得更容易。
为什么不是供应商？
为什么有人不想出售他们的依赖项？以下是我整理的一些原因：
- 大型 VCS 存储库大小。
- VCS 历史充斥着供应商提供的软件包更新。
- 每个项目一个存储库的目标。保持分离干净。
那些供应商包的人
人们广泛谈论 Google 如何使用 vendoring。供应商并不少见，一些外部工具（例如 godep ）可帮助您管理不同应用程序的不同依赖项。
为什么会有人想要供应商？这里有几个原因：
- 任何获取该存储库的人都拥有构建应用程序所需的一切。
- 当 CI/CD 系统不需要获取任何依赖项时，它可以运行得更快。
- 整个应用程序及其依赖项都在一个地方。
一个小的比较
这两种方法都可以解决一些常见问题。无论您是否是供应商，您都可以在本地拥有依赖项，以尽量减少到 Internet 上获取它们的次数。
如果您分叉或以其他方式更改项目依赖项，那么在具有大量更改的大型项目中维护起来可能会很痛苦。我从经验中知道。
请注意，在 Glide 中我们已经解决了分叉项目问题而无需重写导入路径。
另一方面，非供应商的项目不必处理项目管理工具来安装依赖项。以成本或存储库大小为您节省的时间很少。
非供应商的优势之一意味着您确实应该加速版本控制包以获得可靠的构建。这样做时，您就有了 关于安全性和错误处理依赖性的清晰文档 。
需要什么
Go 社区只需要支持那些供应商和那些不作为一等公民的人。在这里支持一个而不是另一个或指定最佳实践可能会走得太远。这是关于项目管理和应用程序管理，而不是语言本身的细微差别。
或者，这是我在与许多不同类型的开发人员合作时构建小型和大型复杂应用程序的多年经验中的 2 美分。
