【发布时间】：2010-09-16 14:58:21
【问题描述】：
如何在 Linux 中分发独立的 Python 应用程序？
我认为我可以理所当然地认为任何现代发行版中都存在最近的 Python 解释器。问题在于处理那些不属于标准库的库，即 wxPython、scipy、python cryptographic toolkit、reportlab 等。
是否有一个可以运行的 Linux 对应物，例如 py2exe（顺便说一下，我从未尝试过）？ 有免费的开源软件吗？
【问题讨论】：
【发布时间】：2010-09-16 14:58:21
【问题描述】：
没有。
Python 在不同的设置方面是出了名的不稳定。部署 python 应用程序的唯一明智的方法是交付您在代码中依赖的整个解释器和库包。这很可能会奏效。
2019 年更新：我支持这一点。 Virtualenv 是一种将库和解释器打包在一起的方式。 Tox 是一个测试工具来测试解释器/依赖矩阵。 Docker 是一种广泛使用的部署包的方式。
【讨论】：
-
这不是我的经验。当然，您可以错误地设置第三方库，甚至错误地安装 python，但通常我从来没有遇到过标准 python 程序的问题。当然，当您使用新功能时移至以前的版本:)。也许您在考虑 Java(tm)？
-
@A.L.Flanagan：实际上，尽管我讨厌 Java，但我发现它在软件分发方面非常强大。
-
也许有更好的最佳答案，但我认为人们可以看到它。当你有这个问题时，实际上应该告诉你的第一件事是：“嗯......没有简单的解决方案，你将不得不处理所有这些设置内容和工具。”
我认为你可以相当安全地认为大多数现代 Linux 发行版上的 python 支持是理所当然的——对于那些没有它的人，只要给出一个理智的错误消息，用户应该能够自己解决如何获得它（您可以为此使用一个简单的 bash 启动脚本）：
#!/bin/bash
if [ -e /usr/bin/python ]
then
echo "Python found!"
else
echo "Python missing!"
fi
【讨论】：
您可以使用cx_Freeze 来执行此操作。它就像 py2exe（将解释器和启动脚本以及所有必需的库和模块捆绑在一起），但适用于 Linux 和 Windows。
它从运行它的环境中收集依赖项，这意味着它们也需要适合目标。如果您正在做一些事情，比如在 32 位 Debian 上构建并在另一个 32 位 Debian 上进行部署，那很好。您可以通过在适当的环境（例如 32 位和 64 位 chroot）中构建多个版本并分发适当的版本来处理 32/64 位差异。如果您想要更通用的东西（例如，在 Debian 上构建，在任何发行版上部署），那么这会有点模糊，具体取决于您的依赖项。
如果你正在做一个相当简单的分发（即你知道你的构建环境和部署环境是相似的），那么这可以避免相当复杂的 rpm/deb/egg/etc 步骤（使用 cx_Freeze 非常容易，尤其是如果你熟悉 py2exe)。如果没有，那么从滚动您自己的依赖安装程序到 deb/rpm/egg/etc 构建的任何操作都将起作用，这取决于您想要做多少工作、您想要提供的所需版本的灵活性以及依赖关系是什么。
【讨论】：
标准的python方式是创建一个python“蛋”。
【讨论】：
Setuptools 对我来说太过分了，因为我的程序的使用非常有限，所以这是我自己开发的替代方案。
我捆绑了一个包含所有先决条件的“第三方”目录，并使用了 site.addsitedir，因此它们不需要全局安装。
# program startup code
import os
import sys
import site
path = os.path.abspath(os.path.dirname(__file__))
ver = 'python%d.%d' % sys.version_info[:2]
thirdparty = os.path.join(path, 'third-party', 'lib', ver, 'site-packages')
site.addsitedir(thirdparty)
我的大多数先决条件都有 setup.py 安装程序。每个捆绑的模块都有自己的“安装”过程，因此任何自定义的东西（例如 ./configure）都可以自动运行。我的安装脚本在安装过程中运行这个 makefile。
# sample third-party/Makefile
PYTHON_VER = `python -c "import sys; \
print 'python%d.%d' % sys.version_info[:2]"`
PYTHON_PATH = lib/$(PYTHON_VER)/site-packages
MODS = egenix-mx-base-3.0.0 # etc
.PHONY: all init clean realclean $(MODS)
all: $(MODS)
$(MODS): init
init:
mkdir -p bin
mkdir -p $(PYTHON_PATH)
clean:
rm -rf $(MODS)
realclean: clean
rm -rf bin
rm -rf lib
egenix-mx-base-3.0.0:
tar xzf $@.tar.gz
cd $@ && python setup.py install --prefix=..
rm -rf $@
【讨论】：
创建一个 deb（适用于所有 Debian 衍生产品）和一个 rpm（适用于 Fedora/SuSE）。将正确的依赖项添加到包装中，您可以合理地确定它会起作用。
【讨论】：
-
我很喜欢创建 deb 或 rpm 作为在 Linux 上打包的“正确方法”，但作为解决方案的问题是：(a) 你必须工作 3 次（一次用于 deb，一次用于 rpm，一次用于其他发行版的源代码版本），然后您必须再次为其他平台（Windows、OSX）执行此操作。为什么不直接使用 PyInstaller，它适用于上述所有功能？
您可能想查看setuptools 中的依赖声明。这可能会提供一种方法来确保正确的包要么在环境中可用，要么可以由具有适当权限的人安装。
【讨论】：
-
我知道@S.Lott 知道这一点，但对其他人来说：这是将 Python 库或应用程序分发给其他开发人员的好方法，他们不介意必须安装正确版本的 Python在您的应用程序正常工作之前。但这绝对是错误的方式分发给最终用户，他们不知道 Python 是什么，绝对不会去安装它来让你的应用程序工作，对于 0.2% 的人来说，他们会安装错误的版本。
您不能轻松地以与分发无关的格式来做到这一点。唯一可靠的依赖跟踪机制内置于发行版的包管理系统中，并且会因发行版而异。您实际上必须为 fedora 执行 rpm，为 ubuntu 和 debian 等执行 debs。
Py2exe 在 Windows 上运行良好。它为启动程序的 python 解释器构建了一个包含所有必要 DLL 和包装器的发行版。安装起来相当简单 - 只需将它放在一个目录中 - 所以为它制作一个 msi 文件很简单。
【讨论】：