4

我有一个项目使用几个（现在〜6个）依赖项（其他库）。它们中的大多数都使用 MIT/简化的 BSD 许可证，因此将它们复制到我的 repo 应该不是问题。

将所有这些库放到我的仓库中并推送它们是一种好习惯吗（当新版本出现时，也更新它们）？或者我的项目回购应该只包含项目文件（代码、资产等）？

优点：

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

缺点：

  • 项目回购膨胀
  • 必须手动更新依赖项
  • 如果我想粘贴还构建的版本，我将不得不粘贴很多
  • 文件，它会占用很多空间，所以可能只坚持源？

  • 一些库可能没有那么好的许可证并直接使用它们（除了要求用户自己获取有效的库之外）并将它们放在我的仓库中可能会带来一些麻烦

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

4

1 回答 1

2

简短的回答：这取决于。

长答案：

在你质疑将代码包含在你的存储库中是否合适之前，你应该问一下是严格控制依赖关系还是更放松是合适的。

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

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

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

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

于 2015-08-23T18:24:55.543 回答