我知道为什么这总体上是好的：更快的安全修复、更容易的打包、更多的功能。然而，我试图说服一些同事，我们不需要将库与我们的程序捆绑在一起。如果没有这个库，它就无法工作，但该库已经稳定了一段时间，并且在可预见的未来仍将如此。我看不出有什么理由不将其拆分。
我可以用什么论据来说服他们？
我的具体情况是这样的：我正在努力符号，这是一个用于符号数学的开源 Python 库。其中一个核心部分是数学，这是一个用于多精度浮点运算的库。没有 mpmath，SymPy 就无法工作，别无选择。因此，它从一开始就与 SymPy 捆绑在一起（我被告知每次导入新版本时通常都会出现一些小的不兼容性需要修复）。还应该指出的是，mpmath 的开发者曾经参与过 SymPy 的开发。现在有一个关于解绑 mpmath 的问题，您可以全部阅读这里。
总结一下那里的讨论：
解绑：
移植到 Python 3 更容易一些（恕我直言，小论点）
更轻松的分发包装
为用户提供更快的（安全）功能更新
“打包和处理依赖关系是难题，但它们已经解决了。这绝对不是我们应该自己做事的领域。”
继续捆绑：
安装。在 Linux 上很容易，在 Mac 上比较困难，在 Windows 上则非常困难。缺乏su访问权限等问题。
它是 SymPy 的一个组成部分，即 sympy 没有它就无法工作（根本）
有不其他包，可以完成 mpmath 的工作
“当我作为用户下载 sympy 时，我希望它能够正常工作。”
这是我的具体情况，但我会接受一个提供良好、一般答案的答案。
答案1
除了您提到的优点（安全性、包装、功能）之外，我还可以想到更多：
如果有人发现该功能对另一个程序有用，则无需进行将其拆分的工作。也就是说，如果她首先知道该功能是否以库的形式存在于您的项目中。这取决于它的设计得如何......如果您的项目足够模块化。
如果这对其他项目有用，这通常会减少磁盘使用的大小（例如，仅一份代码副本）。
这将提高代码的质量，迫使您进行一些（急需的）重构。与上面的第一点一样，这也取决于代码的质量。
增加图书馆的用户数量（如果将其分开）将有助于使其更加通用，这也可能会提高其质量。
答案2
还有另一个答案，但我认为这是最重要的一个（只是我个人的观点），尽管其他答案也都是很好的答案。
单独打包 lib 允许更新 lib，而不需要更新应用程序。假设库中存在错误，您不仅可以更新库，还必须更新整个应用程序。这意味着您的应用程序需要版本升级，而其代码甚至没有更改，只是因为库。
答案3
虽然优点很明显，但易于部署似乎是在您的案例中将库与程序一起发布的主要论点。
以下是一些反对捆绑的更多论点：
在 Linux 中，发行版维护人员的工作是确保您的库与其依赖项正常工作。无论如何，大多数用户都会使用发行版的包管理器下载该库。那些使用 trunk 的人通常不会介意花时间配置库。
在 Windows 和 Mac OS 中，通常会使用 pip 等 Python 包管理器，因为手动安装库很麻烦。
甚至还有关于硬部署到 Google 应用引擎的争论，但并非所有 Web 框架都在其上运行。许多甚至需要移植，库的磁盘空间有限，而且毕竟是 Web 应用程序托管！ Web 应用程序不太可能使用符号数学。
如果依赖项不可用或版本错误，没有人会阻止您显示干净的错误消息。
当程序认为自己比他们聪明时，人们常常讨厌它。让用户照顾自己的系统。
答案4
一种尺寸不必适合所有尺寸。
对于源发行版，如果您进行捆绑，许多发行版（至少是 Debian 和 Fedora 传统）上的打包者将不得不做额外的工作来禁用或删除捆绑，因为这些平台的软件包策略禁止或至少强烈阻止捆绑。因此，通过捆绑，您会为下游创造更多的工作，但收益却微乎其微。这个论点可能有一定的分量吗？
二进制发行版（如果您提供的话）可以采用任何一种方式；捆绑对于这些可能是有意义的，因为下游不使用它们。
但您没有理由不能做出相反的决定并为 Windows 和 Mac 安装程序提供捆绑包。