VPe*_*ric 10 package-management
我知道为什么这总体上是好的：更快的安全修复，更容易的打包，更多的功能。但是，我试图说服一些同事，我们不需要将库与我们的程序捆绑在一起。如果没有这个库，它将无法运行，但该库现在已经稳定了一段时间，并且在可预见的未来仍将如此。我看不出有任何理由不将其解绑。
我可以用什么论据来说服他们？
我的具体情况是这样的：我正在研究SymPy，它是一个用于符号数学的开源 Python 库。它的核心部分是mpmath，它是一个用于多预置浮点运算的库。SymPy 没有 mpmath 就无法工作，别无选择。因此，它从一开始就与 SymPy 捆绑在一起（有人告诉我，每次导入新版本时，通常都会有一些小的不兼容性需要修复）。还需要注意的是，mpmath 的开发者曾经参与过 SymPy 的开发。现在有一个关于拆分 mpmath 的问题，您可以在这里阅读全部内容。
总结那里的讨论：
解绑：
移植到 Python 3 稍微容易一些（恕我直言，次要参数）
更易于分发的打包
为用户提供更快的（安全）功能更新
“打包和处理依赖是难题，但它们已经解决了。这绝对不是我们应该做自己的事情的领域。”
继续捆绑：
安装。在 Linux 上很容易，在 Mac 上更难，在 Windows 上非常困难。缺乏su访问等问题。
它是 SymPy 的一个组成部分，即 sympy 没有它就不能工作（根本）
有没有其它的包，可以做mpmath的工作
“当我作为用户下载 sympy 时，我希望它能够正常工作。”
这是我的具体情况，但我会接受一个也能提供良好、一般性答案的答案。
除了您提到的优势（安全性、包装、功能）之外，我还能想到更多：
发现该功能对另一个程序有用的人不需要将其拆分。也就是说，如果她甚至首先知道该功能是否以库的形式存在于您的项目中。这取决于它的设计有多好……如果您的项目足够模块化。
在这对其他项目有用的情况下，这通常会减少磁盘使用的大小（例如，只有一份代码副本）。
这将提高您的代码质量，迫使您进行一些（急需的）重构。与上面的第一点一样，这也取决于代码的质量。
增加库的用户数量（如果它被拆分）将有助于使其更通用，这也可能会提高它的质量。
另一个答案，但我认为是最重要的（只是我个人的意见），尽管其他答案也是很好的答案。
单独打包 lib 允许在不需要更新应用程序的情况下更新 lib。假设 lib 中存在错误，而不仅仅是能够更新 lib，您还必须更新整个应用程序。这意味着您的应用程序将需要一个版本提升，而其代码甚至没有更改，仅仅因为 lib。