是否将所有项目依赖项放在项目的存储库中？

Question

我有一个使用couple（现在~6个）依赖项（其他库）的项目。他们中的大多数都是麻省理工学院/简单的BSD许可证，所以将它们复制到我的仓库应该不是问题。

将所有这些库放到我的仓库并推送它们（当新版本到来时，也会更新它们）是不错的做法？或者我的项目仓库应该只包含项目文件（代码，资产等）？

优点：

• 建筑是如此简单，因为我拥有所有我需要永远关闭的东西
• 添加库意味着我使用这些版本测试了我的项目，因为其他版本（旧版/更新版）可能会产生一些问题

缺点：

• 项目回购中的膨胀
• 必须手动更新依赖项
• 如果我想粘贴内置版本，我将不得不粘贴很多
• 文件，它需要很大的空间，所以可能坚持使用源代码 仅？

• 某些图书馆可能没有那么好的许可证并直接使用它们（除了要求用户自己获取有效的图书馆）并将它们放入我的回购中可能会造成一些麻烦

• 有更多的项目来保持依赖关系意味着我必须同时为所有项目更新它们（例如，如果我根据当前项目（它的库）制作一些其他项目，那么它们都会有相同的dependnecies）

Answer 1

简短回答：这取决于。

答案很长：

在您质疑是否适合将代码包含在存储库中之前，您应该询问是否适合严格控制依赖关系或更轻松。

答案取决于您分发项目的方式，客户/用户的需求，是否需要对依赖项进行任何源代码更改以及任何其他项目要求。

例如，假设您销售的是硬件设备，而您的代码是设备的固件。在这种情况下，您可能希望严格控制依赖项（需要非常具体的版本）。这使您可以完全控制整个系统，从而简化系统测试，如果您的设备受到某些安全性，安全性或可靠性要求（例如，它是医疗设备或发送给Pluto的探头），这一点非常重要。通常，如果您以二进制文件或文件系统映像的形式分发产品，那么您可能希望使用固定的依赖关系。

如果您希望用户能够动态链接其系统附带的任何依赖项版本（由于许多原因（包括安全更新）很有价值），那么您可能希望放宽这些要求。明确支持哪些版本，将自己限制在这些版本中可用的文档化API，使用工具来强制执行要求（如果依赖项太旧则出错），并针对尽可能多的依赖项版本测试代码

一旦您知道控制依赖关系的严密程度，就可以选择用于管理它们的机制。您可以使用像Apache Ivy这样的工具来自动获取依赖项，使用GNU Autoconf来强制执行特定版本，或者您可以将代码拉入Git存储库并自行构建。具体的选择并不重要;使用满足您要求的任何内容，对您和您的用户来说都是最简单的。