为什么图书馆要单独运送而不是与每个程序捆绑在一起？

我知道总体上为什么如此好：更快的安全修复，更轻松的包装，更多功能。但是，我试图说服一些同事我们不需要将库与程序捆绑在一起。没有该库，它将无法正常工作，但是该库已经稳定了一段时间，并且在可预见的将来仍将保持稳定。我认为没有任何理由不将其拆开。

我可以用什么论据来说服他们？

我的具体情况是：我正在研究SymPy，这是一个用于符号数学的开源Python库。它的核心部分是mpmath，它是用于多预置浮点运算的库。如果没有mpmath，SymPy将无法运行，没有其他选择。因此，它从一开始就与SymPy捆绑在一起（有人告诉我，每次导入新版本时通常都存在一些小的不兼容问题来修复）。还应注意，mpmath的开发人员曾经参与过SymPy开发。现在有一个关于捆绑mpmath的问题，您可以在这里阅读全部内容。

总结那里的讨论：

解除捆绑：

• 移植到Python 3稍微容易一些（次要参数IMHO）

• 包装更容易分发

• 向用户更快（安全）功能更新

• “打包和处理依赖关系是棘手的问题，但可以解决。绝对不是我们应该做自己的事情的领域。”

继续捆绑：

• 安装。在Linux上很容易，在Mac上更难，在Windows上非常难。缺少su访问权限和其他问题。

• 它是SymPy不可或缺的一部分，即没有它，sympy根本无法工作（根本）

• 有没有其它的包，可以做mpmath的工作

• “当我作为用户下载sympy时，我希望它能正常工作。”

那是我的具体情况，但我会接受一个提供一般性好的答案的答案。

还有另一个答案，但我认为是最重要的（只是我个人的看法），尽管其他答案也都是不错的答案。

单独打包lib可允许更新lib，而无需更新应用程序。假设库中存在一个错误，而不仅仅是能够更新该库，则必须更新整个应用程序。这意味着您的应用程序由于lib的原因，甚至需要更改版本代码，而无需更改其代码。

除了您提到的优势（安全性，包装，功能）之外，我还能想到其他一些优势：

• 会发现该功能对另一个程序有用的人无需进行将其拆分的工作。那就是说，她甚至不知道该功能是否首先以库的形式存在于您的项目中。这取决于设计的好坏...如果您的项目足够模块化。

• 如果这对于其他项目有用，则通常可以减少光盘使用量（例如，仅复制一份代码）。

• 这将提高代码的质量，迫使您进行一些（非常需要的）重构。与上面的第一点一样，这也取决于代码的质量。

• 增加图书馆用户的数量（如果图书馆被拆分）将有助于使其更通用，这也可能会改善图书馆的质量。

尽管优势显而易见，但易于部署似乎是将库与程序一起交付的主要理由。

这里还有一些反对捆绑的论点：

• 在Linux中，分发维护者的工作是确保您的库与其依赖项一起正常工作。无论如何，大多数用户将使用发行版的程序包管理器下载该库。那些使用中继的人通常不会介意花费时间来配置库。

• 在Windows和Mac OS中，无论如何通常都会使用pip之类的Python包管理器，因为手动安装库很麻烦。

• 甚至有关于硬部署到Google应用程序引擎的争论，但并非所有Web框架都在其上运行。许多甚至需要移植，库的磁盘空间有限，而且毕竟是Web应用程序托管！Web应用程序不太可能使用符号数学。

• 如果依赖项不可用或版本不正确，没有人会阻止您显示干净的错误消息。

• 当程序认为自己比自己聪明时，人们通常会讨厌它。让用户照顾自己的系统。

处理Windows Installer软件包中未捆绑销售商品的正确方法是对库的存在进行preinst测试，如果不存在，则建议从软件安装程序包中包含的库软件包中进行安装。我敢肯定，大多数具有Windows端口的GTK应用程序都遵循这些原则-我知道pidgin可以。

一种尺寸不一定适合所有尺寸。

对于源代码发行版，如果进行捆绑，则许多发行版（至少是Debian和Fedora遗产）上的打包程序将不得不做更多的工作来禁用或删除捆绑，因为这些平台的打包策略禁止或至少不鼓励捆绑。因此，通过捆绑，您将为下游创建更多的工作，而几乎没有收益。这个论点可能有分量吗？

二进制发行版（如果您提供的话）可以任意选择。捆绑对于这些可能很有意义，因为下游不使用它们。

但是没有理由不能对Windows和Mac安装程序做出相反的决定和捆绑。

捆绑与依赖是包装界的一个古老争论。本文档介绍了这两种思想流派：http : //www.aosabook.org/en/packaging.html