如何处理依赖项源版本问题

Question

如果项目依赖于某些库，则基本上有两种选择：

1. 在众所周知的全局路径中找到库（例如/usr/src/linux-headers-4.13.0-1-amd64/
2. 将源复制到项目文件夹中。

使用全球定位方法需要最少的空间和时间（下载时间）。如果依赖项版本很好（标记为v3.1，v3.1.1等等），则此选项效果很好。

如果我们的项目需要使用库的最新提交，则版本控制不是一种选择。如果我们只是将最新的提交提取到众所周知的位置并让我们的项目使用库，那么我们很可能在6个月后无法编译我们的项目，这是不可接受的。

如果我们将依赖项作为子项目添加到项目中，我们将始终能够编译项目。这是最安全的方法。问题是，如果库大约100MB，将源复制到项目文件夹只是浪费磁盘使用，下载时间等...

人们如何处理这个问题？

Answer 1

你不能吃蛋糕并吃掉它：

• 您要么依赖一个稳定的版本化库，然后引用它（无论它位于何处）

• 或者你将永远依赖“最新和最伟大的” - 然后参考那份

磁盘空间不是一个真正的问题 - 显然你需要在你的开发者机器上至少拥有一次你使用过的lib的本地副本，如果它是一个“正确的版本化”代码，它就没有区别。树干头“。当它始终是“主干”时，您可能会使用某些版本控制系统（如git或svn）来获取库，因此每当您更新本地副本时，您只会从回购中提取更改，而不是“完整” 100 MB“。

但是，为了使您的构建可重现，对于每个版本的源代码，您应该将所有依赖项与源代码一起版本化。如果您使用的是第三方库，则可以

• 依靠供应商为您提供您在项目期间使用的完全版本，并期望他们在未来10年左右为您提供这些版本

• 或者，保留您自己使用的第三方库的每个版本的副本（也可能将它们放在您自己的源代码库中）。这是我一直喜欢的专业发展方法，谁知道图书馆供应商是否仍在下周，下个月，明年维护他的东西？

Answer 2

这是您同时可以吃蛋糕的方式（请参阅量子物理学）：

1. 使用它们自己的分布式版本控制系统（git，hg，bazaar等）在全局位置维护您的依赖项（库）。 （请参阅注释1）
2. 在项目文件夹中维护依赖项版本数据库（文本文件），并在每次构建时对其进行更新。 （格式：MyLibrary commit-hash-or-version）

项目将始终使用最新版本的依赖项。如果某个时候编译失败（例如，当您尝试在3年后编译项目时），

1. 开始获取在上一个成功的构建点使用了哪个版本的依赖项
2. 使用该哈希值在临时位置创建依赖项的签出。
3. 将临时位置指向您在构建过程中的依赖路径。

很明显，此“返回成功点”过程可以轻松实现自动化。

  

注1：依赖关系并不只是源代码，它们可能只是二进制格式的一些工具。在这种情况下，依赖项管理器挂钩应使用--version参数（或适用于该工具的参数）调用该工具，获取版本，并附加到dependencies.txt文件中。显然，您应该准备好能够获得该工具的旧版本，以防将来在某个时候需要它。