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