我应该将C库与我的Python应用打包吗？
如果我有一个Python包，它需要一些C语言的库（比如说用于数值计算的Gnu科学库（GSL）），把这个库和我的代码打包在一起是个好主意吗？
我希望我的包能让用户尽可能简单地安装，不想让他们手动下载C库，还要提供包含路径。而且，我可以确保我提供的库版本和我的代码是兼容的。
不过，如果用户已经安装了这个库，会不会出现冲突？或者还有其他原因让我不要这样做吗？
我知道我可以通过提供一个二进制版本来让用户更方便，但我不想为所有可能的操作系统维护二进制版本。所以，我想坚持使用源代码分发，但对于那些自豪拥有C编译器的用户来说，安装应该像python setup.py install这样简单。
3 个回答
你可以把源代码分成两个不同的分支，一个分支里包含库文件，另一个分支里没有。这样的话，如果用户安装了库文件，你就可以明确地提醒他们。还有一种解决办法是（如果这些库的许可证允许的话），把它们打包成一个文件。
我觉得没有唯一的解决方案，但这是我目前想到的一些想法。
祝你好运！
你可以使用 virtualenv 来为你的应用创建一个独立的Python环境。这样可以避免和其他库发生冲突。最好是使用 Distribute 来打包你的模块和依赖，比如你的库。还有 Distutils 也是值得了解的东西。
软件项目中，发布是一个比较难的部分。Java和.NET通过定义一个标准的运行环境来减轻这个负担，然后就说“只需发布其他所有东西”。当然，这样也有个缺点：所有的代码都必须用这个运行环境支持的语言重写——一旦你想使用本地代码，就会失去所有的优势。
在Python中，这个问题更复杂，像Ruby、C、C++等语言也是如此，因为它们通常依赖现有的本地库。
一般来说：
确保可以通过像pypi.python.org这样的地方获取源代码的sdist（源代码分发包）。正确设置你的install_requires（你可能需要GSL的Python绑定，而不是GSL本身）。使用标准的setuptools/distribute布局。这样，任何人——比如说某个发行版的包维护者——都可以拿到你的软件并进行打包。
另外，考虑为你的用户提供一个完整的可安装包。你不需要支持所有的发行版和操作系统；选择一两个你认为会被广泛使用的。像PyInstaller这样的工具可以让你为许多操作系统创建一个可安装、可运行的包，但特别是在Linux上，你可能希望用户安装发行版自带的转递依赖（比如libgsl？）——你需要一个完整的deb或rpm包来满足这个需求——同样，不要试图支持所有的发行版，这样会让你崩溃。支持你最常用的那些，让其他用户来帮助你处理其他打包需求。
同时也可以看看Python打包指南