Python中如何将Python运行环境打包并迁移到其他机器
在本机编好的脚本，因为本机和远程 VPS 的 python 环境不一样，想打包一份运行环境到远程的 VPS 上，试了下 virtualenv 好像只能本地隔离，在 VPS 上解压后 python 版本没有变化。
virtualenv 不能处理这个事情吗？或者有其它的替代方案？
本机系统：mac os
本机 python 版本：3.5.1
VPS python 版本：2.7.5
VPS 系统：CENTOS
我的操作是这样的
virtualenv --no-site-packages venv
...
source venv/bin/activate
Python中如何将Python运行环境打包并迁移到其他机器
这个问题很常见，尤其是在需要离线部署或者确保环境一致性的场景下。核心思路是打包整个解释器、依赖库和你的代码，而不是只迁移 pip 包列表。
最直接、最可靠的方法是使用 虚拟环境 配合 打包工具。这里我推荐用 venv 创建环境，然后用 shiv 或 PyInstaller 来生成一个独立的可执行文件或包。不过，对于迁移整个运行环境，shiv 的方式更干净。
下面是一个完整的、可运行的示例，展示如何用 shiv 创建一个自包含的 .pyz 文件，它可以在没有Python的机器上运行（只要架构一致）。
1. 在你的开发机器上操作
首先，确保你的项目有一个标准的 requirements.txt 文件。然后，安装 shiv 并打包。
# 1. 安装 shiv
pip install shiv
# 2. 创建一个入口点脚本，比如叫 app.py
# 假设你的主程序入口是 main 函数
cat > app.py << 'EOF'
def main():
print("Hello from the bundled app!")
# 你的实际应用逻辑从这里开始
if __name__ == "__main__":
main()
EOF
# 3. 使用 shiv 打包
# -o app.pyz 指定输出文件名
# -e app:main 指定入口点（模块名:函数名）
# -r requirements.txt 指定依赖
shiv -o app.pyz -e app:main -r requirements.txt .
2. 在目标机器上运行
将生成的 app.pyz 文件拷贝到目标机器（无需安装Python）。直接运行即可：
# 赋予执行权限（Linux/Mac）
chmod +x app.pyz
# 运行
./app.pyz
原理说明：
shiv 会将 Python 解释器、所有依赖库以及你的代码打包成一个单独的 .pyz 文件。首次运行时，它会在用户家目录的 .shiv 文件夹下解压缓存，后续运行就很快了。这完美解决了环境迁移问题。
另一种情况：如果你需要完整的、可移植的 Python 解释器文件夹
有时你可能需要整个绿色版Python文件夹。可以用 venv 打包：
# 1. 创建虚拟环境，包含所有依赖
python -m venv my_project_venv
source my_project_venv/bin/activate # Linux/Mac
# 或 my_project_venv\Scripts\activate # Windows
pip install -r requirements.txt
pip install your_package .
# 2. 将整个 my_project_venv 文件夹压缩并拷贝到目标机器
# 目标机器需要相同操作系统和架构，并设置好环境变量或使用绝对路径调用 venv 中的 Python
总结建议：对于大多数项目，直接用 shiv 打包成单个文件是最省事的。
推荐用 https://github.com/jazzband/pip-tools 以固化版本号的方式管理 python 依赖，pip freeze 会带来一堆没必要的依赖。之后你在远程的虚拟机上初始化 virtualenv 安装 requirements.txt 定义好的依赖。virtuelenv 只能提供 python module 层次上的隔离，如果你追求操作系统（内核层以上）的隔离，可以用 docker.
一般情况下建议用 pip-tools 固化版本号，同时在 Dockerfile 中定义如何安装系统包以及 python module, 这样远程虚拟机只要构建出 docker image 就可以直接跑了。
如果 VPS 的 python 版本可以升级的话，可以考虑在本机上编译安装目标机上相同版本的 python，然后安装所有需要的 python 包，把所有的软件包打包成.whl 格式，到目标机器上直接 pip install 安装。
我之前也问过相同的问题…目前个人感觉是这样，如果能上 docker 的话最好上 docker。我这边比较特殊，生产环境不让上 docker，我的做法比较取巧，是在生产上和开发上安装相同的 gcc 版本和 python 版本，开发环境使用 virtualenv，开发好了直接把整个 virtualenv 打包，放在生产环境上相同的目录结构下（一定要是相同的目录结构，不然 source activate 后配置会出问题）然后就可以直接跑了…
我的开发环境是 centos，生产环境是 redhat，目前运行没有问题…
