如果我有一个依赖于某些 C 库（例如用于数值计算的 Gnu 科学库 (GSL)）的 Python 包，将库与我的代码捆绑在一起是个好主意吗？
我想让我的包尽可能易于用户安装，我不希望他们必须手动下载 C 库并提供包含路径。此外，我始终可以确保我发布的库版本与我的代码兼容。
但是，如果用户已经安装了库，是否可能会发生冲突，或者我不应该这样做的任何其他原因？
我知道我可以通过提供二进制发行版让用户更轻松，但我想避免为所有可能的操作系统维护二进制发行版。所以，我想坚持使用源代码分发，但对于用户（自豪地拥有 C 编译器）来说，安装应该像 python setup.py install 一样简单。
【问题讨论】：
分发是任何软件项目的难点之一。 Java 和 .NET 通过定义标准运行时减轻了部分负担，然后只是说“只是分发其他所有内容”。当然有一个缺点：所有东西都必须用运行时支持的语言重写——一旦你想使用本机代码，你就失去了所有的优势。
这在 Python 中更难，因为它在 Ruby、C、C++ 和其他语言中，因为它们通常利用现有的本机库。
一般来说：
以 pypi.python.org 为例，可以获取源 sdist。正确设置您的 install_requires （可能您需要 GSL 的 python 绑定，而不是 GSL 本身）。使用标准的 setuptools/distribute 布局。这将让任何人 - 比如说任何发行版的包维护者 - 拿起您的软件并将其打包。
此外，考虑为您的受众提供一个成熟的可安装包。您不必支持所有发行版和操作系统；选择您认为最常用的一两个。像PyInstaller 这样的工具可以让你为许多操作系统创建一个可安装、可运行的包，但尤其是对于 linux，你可能希望用户安装发行版自己的传递 deps 版本（libgsl？）——你需要一个成熟的deb 或 rpm 包来满足这一点 - 再次，不要尝试支持任何和所有发行版，你会生气的。支持您最常用的东西，并让其他用户帮助您解决其他包装需求。
【讨论】：
您可以有两个独立的 src 分支，一个包含库，另一个不包含。这样，您可以明确警告您的用户，以防他们安装了库。另一种解决方案可能是（如果库的许可证允许您）将它们包装在一个文件中。
我认为没有唯一的解决方案，但这是我目前能想到的想法。
祝你好运
【讨论】：
您可以使用virtualenv 为您的应用程序创建私有 Python 环境。这避免了与其他库的冲突。最好使用 Distribute 打包模块和依赖项，例如库。 Distutils 是另外一个值得研究的东西。
【讨论】：