什么时候（不）适合将依赖项与应用程序捆绑在一起？

Question

摘要

我最近与我的应用程序所依赖的框架的创建者进行了对话。在那次谈话中，他提到了一种说法，如果我将他的框架与我的应用程序捆绑在一起并将最终用户提供给我认为与我的代码一致的版本，那么它将使我的生活变得更简单。直觉上我一直试图避免这样做，事实上，我已经花了很多精力来分割我自己的代码，以便可以在不占用整个项目的情况下重新分配部分代码（即使很少有机会重复使用任何代码。它）。然而，在考虑了一段时间后，我无法想出一个特别好的理由为什么我这样做。事实上，现在我已经考虑过了，我看到一个非常引人注目的案例来捆绑所有我的较小的依赖项。我已经提出了一系列利弊，我希望有人可以指出我所遗漏的任何东西。

赞成

• 版本的一致性意味着更容易 测试和故障排除。
• 申请可能会更广泛 观众因为似乎有 要安装的组件更少。
• 对依赖的小调整可以 更容易下游和 与申请一起交付， 而不是等待他们 渗透到上游代码库中。

缺点

• 包括更复杂的包装流程 的依赖关系。
• 用户最终可能会有多份副本 依赖他们的机器。
• 根据bortzmeyer的回应，由于无法升级单个组件，因此存在潜在的安全问题。

备注

作为参考，我的应用程序是用Python编写的，我所引用的依赖项是“轻量级的”，我的意思是小而不常用。 （所以它们并不存在于所有机器上，甚至不存在于所有存储库中。）当我说“package with”我的应用程序时，我的意思是在我自己的源代码树下分发，而不是使用驻留在我的包中的脚本安装，所以会没有冲突版本的机会。我也只是在Linux上开发，所以不用担心Windows安装问题。

所有这些，我有兴趣听到有关包装依赖性更广泛（语言无关）问题的任何想法。有什么我想念的，或者这是一个简单的决定，我只是过度思考？

附录1

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

Answer 1

我赞成捆绑依赖项，如果使用系统进行自动依赖性解析（即setuptools）是不可行的，而 if 则可以在不引入版本冲突的情况下进行捆绑。您仍然需要考虑您的申请和受众;严肃的开发人员或爱好者更有可能希望使用特定（最新）版本的依赖项。捆绑内容对他们来说可能很烦人，因为这不是他们所期望的。

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

我不在乎我的磁盘库有多少副本，只要它们没有互相帮助。磁盘空间确实非常便宜。

Answer 2

难道你不能只依赖某些版本的依赖项吗？例如。在使用setuptools的Python中，您可以指定所需的确切版本，甚至可以提供一些条件，例如＆lt; =＆gt;这当然只适用于Python和特定的包管理器，但我个人总是首先尝试不捆绑所有内容。通过将其作为Python egg发布，您还将自动安装所有依赖项。

您当然也可以使用双向策略为您自己的软件包提供仅包含依赖项的链接，然而在某些安装程序（如时尚）中提供完整的设置。但即便如此（在python案例中）我建议简单地用它捆绑鸡蛋。

有关鸡蛋的一些介绍，请参阅this post of mine。

当然这是特定于Python的，但我认为其他语言可能有类似的打包工具。

Answer 3

如果您为最终用户制作软件，目标是让客户使用您的软件。阻碍任何阻碍的都是适得其反的。如果他们必须自己下载依赖项，他们可能会决定避免使用您的软件。您无法控制库是否向后兼容，并且您不希望软件因用户更新其系统而停止工作。同样，您不希望客户使用旧库安装旧版本的软件，并让系统的其余部分中断。

这意味着捆绑通常是要走的路。如果您可以确保您的软件能够顺利安装而不捆绑依赖项，而且工作量较少，那么这可能是更好的选择。这是关于满足客户需求的。

Answer 4

对于Linux，甚至不要考虑捆绑。你并不比包裹经理或包装商更聪明，每个发行都采用自己的方式 - 如果你试图按照自己的方式行事，他们就不会高兴。充其量，他们不会打扰你的应用程序，这不是很好。

请记住，在Linux中，会自动为您提供依赖项。这不是让用户得到它们的问题。它已经为你完成了。

对于Windows，随意捆绑，你自己就在那里。

Answer 5

在使用应用程序捆绑库/框架/等的缺点中似乎已经忘记了一个重要的观点：安全更新。

大多数Web框架都充满了安全漏洞，需要经常修补。无论如何，任何库都可能需要升级一天或另一天才能出现安全漏洞。

如果您没有捆绑，系统管理员只会升级该库的一个副本并根据应用程序重新启动。

如果捆绑，系统管理员可能甚至不知道他们必须升级。

因此，捆绑的问题不在于磁盘空间，而是存在旧版和危险副本的风险。

Answer 6

就我的经验而言，带上一粒盐。

我对我创作的几个开源库的偏好是为了尽可能地独立于其他库。原因是，我不仅要与我一起分发额外的库，我还有义务更新我的应用程序以实现兼容性，因为其他库也会更新。

从我从其他带有“常见”库依赖关系的库中使用的库中，我最终总是需要在我的系统上使用多个版本的公共库。我正在使用的利基库的相对更新速度并不那么快，而公共库的更新频率更高。版本化地狱。

但那是一般性的说法。如果我可以通过合并依赖项来帮助我的项目和用户，我总是会关注该决策的下游和后期影响。如果我可以管理它，我可以自信地包含依赖项。

与往常一样，您的里程可能会有所不同。

Answer 7

我总是包含我的网络应用程序的所有依赖项。这不仅使安装更简单，而且即使系统上的其他组件升级，应用程序也能保持稳定并按预期方式工作。

Answer 8

注意再现经典的Windows DLL地狱。通过各种方式最大限度地减少依赖项的数量：理想情况下，只需依赖于您的语言及其框架，如果可以的话，别无其他。

毕竟，保留硬盘空间不再是目标，因此用户无需关心多个副本。此外，除非您的用户数量极少，否则请务必承担自己的包装责任，而不是要求他们获取所有依赖项！