将所有项目依赖项放入项目存储库中是一个好的做法吗?

问题描述 投票:0回答:2

我有一个使用几个(目前〜6)依赖项(其他库)的项目。它们中的大多数都使用 MIT/简化的 BSD 许可证,因此将它们复制到我的存储库应该不是问题。

将所有这些库放入我的存储库并推送它们(当新版本出现时,也更新它们)是否是一个好习惯?或者我的项目仓库应该只包含项目文件(代码、资产等)?

优点:

  • 构建变得更加简单,因为我需要的一切都在附近
  • 添加的库意味着我使用这些版本测试了我的项目,因为其他版本(较旧/较新)可能会产生一些问题

缺点:

  • 项目存储库中的膨胀

  • 必须手动更新依赖项

  • 如果我想粘贴也构建的版本,我将不得不粘贴很多

  • 文件,这会占用大量空间,所以可能会坚持使用源代码 仅?

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

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

c++ git dependencies repository repository-design
2个回答
4
投票

简短回答:这取决于。

长答案:

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

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

例如,假设您正在销售硬件设备,并且您的代码是设备的固件。在这种情况下,您可能希望严格控制依赖项(需要非常特定的版本)。这使您可以完全控制整个系统,从而简化系统测试,并且如果您的设备受到某些安全、安保或可靠性要求(例如,它是医疗设备或发送到冥王星的探测器),这可能很重要。一般来说,如果您以二进制或文件系统映像的形式分发产品,您可能需要使用固定依赖项。

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

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


0
投票

如果他们有许可证,我将按照以下说明遵循许可证:

https://medium.com/@Vertexwahn/is-putting-all-project-dependency-inside-projects-repository-good-practice-2b275f4fc3ce

但是如果他们没有许可证,我认为最好的方法是创建一个静态分叉,并且仅根据需要使用原作者的更改来更新它,并且只需提供该分叉的链接,因为:

https://docs.github.com/articles/licensing-a-repository#:~:text=然而%2C%20没有%20a%20license%2C%20,包括%20an%20open%20source%20license

“但是,如果没有许可证,则适用默认版权法,这意味着您保留对源代码的所有权利,任何人都不得复制、分发您的作品或根据您的作品创建衍生作品。如果您正在创建开源项目,我们强烈建议您添加开源许可证。”

© www.soinside.com 2019 - 2024. All rights reserved.