何时（不）将依赖项与应用程序捆绑在一起？

Question

摘要

我最近和我的一个应用程序所依赖的框架的创建者进行了一次谈话。在那次谈话中，他还提到，如果我把他的框架与我的应用程序捆绑在一起，并向最终用户交付一个我知道与我的代码一致的版本，那会让我的生活更简单。直觉上，我一直试图避免这样做，事实上，我花了很大的力气来分割我自己的代码，这样就可以在不占用整个项目的情况下重新分发部分代码（即使在几乎没有人会重用任何代码的情况下）。然而，经过一段时间的思考，我还没有找到一个特别好的理由来解释为什么我要这么做。事实上，现在我已经考虑过了，我看到了一个非常有说服力的案例来捆绑我的小依赖。我列出了一份利弊清单，希望有人能指出我遗漏的任何东西。在

专业人士

• 版本一致意味着更容易 测试和故障排除。在
• 应用范围可能更广 既然有观众 要安装的组件更少。在
• 对依赖关系的小调整可以 更容易在下游和 随申请书一起交付， 而不是等待他们 渗透到上游代码库中。在

缺点

• 更复杂的包装过程包括 依赖关系。在
• 用户可能会得到多个副本 对他们机器的依赖。在
• 根据bortzmeyer的回应，无法升级单个组件存在潜在的安全隐患。在

注意事项

作为参考，我的应用程序是用Python编写的，我引用的依赖关系是“轻”的，我的意思是很小而且不常用。（所以它们不存在于所有机器上，甚至不存在于所有存储库中）当我说“打包到”我的应用程序时，我的意思是在我自己的源代码树下分发，而不是用驻留在我的包中的脚本安装，这样就不会有版本冲突的可能。我也只在Linux上开发，所以不需要担心Windows安装问题。在

尽管如此，我也有兴趣听到关于更广泛（独立于语言）的打包依赖性问题的任何想法。是我遗漏了什么，还是这是一个简单的决定，我只是想了想？在

附录1

值得一提的是，我对下游包装商的需求也相当敏感。我希望尽可能直接地将应用程序打包到特定于发行版的Deb或RPM中。在

Answer 1

如果您为最终用户开发软件，那么目标是让客户使用您的软件。任何阻碍的事情都会适得其反。如果他们必须自己下载依赖项，那么他们有可能决定不使用您的软件。你不能控制库是否向后兼容，你也不希望你的软件因为用户更新了他们的系统而停止工作。类似地，您也不希望客户安装带有旧库的旧版本软件，而让系统的其余部分崩溃。在

这意味着捆绑销售通常是可行的。如果你能确保你的软件能够顺利地安装而不捆绑依赖关系，并且工作量更少，那么这可能是一个更好的选择。关键是什么让你的顾客满意。在

Answer 2

我喜欢绑定依赖项，如果使用系统自动解析依赖项（即setuptools）是不可行的，如果您可以在不引入版本冲突的情况下完成它。您仍然需要考虑您的应用程序和您的受众；严肃的开发人员或爱好者更可能希望使用依赖项的特定（最新）版本。捆绑在一起对他们来说可能很烦人，因为这不是他们所期望的。在

但是，特别是对于应用程序的最终用户，我严重怀疑大多数人是否喜欢搜索依赖关系。至于有重复的拷贝，我宁愿花额外的10毫秒来下载一些额外的千字节，或者在额外的meg磁盘空间上花费任何一分钱，而不是花10多分钟搜索网站（可能会关闭）、下载、安装（如果版本不兼容，可能会失败）等等

我不在乎磁盘上有多少个库的拷贝，只要它们不妨碍彼此。磁盘空间真的非常便宜。在

Answer 3

你不能仅仅依赖于这些依赖关系的某个版本吗？E、 g.在带有setuptools的Python中，您可以指定它需要的确切版本，甚至可以给出一些条件，如<；=>；等。这当然只适用于Python和特定的包管理器，但我个人总是首先尝试不绑定所有的东西。将其作为Python鸡蛋发布后，您还将自动安装所有依赖项。在

当然，您也可以使用双向策略来提供您自己的包，只提供到依赖项的链接，并且以类似安装程序的方式提供完整的设置。但即便如此（在python的例子中），我还是建议简单地把鸡蛋和它捆绑在一起。在

有关鸡蛋的介绍，请参见this post of mine。在

当然，这是非常特定于Python的，但是我假设其他语言可能有类似的打包工具。在