如何基于pipenv虚拟环境打包安装Python CLI应用至生产环境

• 「生产环境必须为每个应用做独立依赖隔离，禁止直接向全局site-packages安装包」的判断完全正确，全局装包导致的共享依赖版本冲突是Python生产部署最高发的故障诱因之一。
• 你目前的思路偏差核心是混淆了两类Python项目的交付逻辑：一类是发布到公共/私有源给其他开发者引入的通用库、CLI工具，需要打标准分发包；另一类是自主可控的后端服务、内部应用，生产部署完全不需要走标准分发包安装流程，你之前尝试把服务打成pip可安装包再部署的路径本身就走偏了。
• 「剔除requirements.txt里的冲突依赖降低全局影响」的操作没有必要：独立虚拟环境的依赖是全量私有的，哪怕和其他应用使用同一个包的不同版本，也会在各自环境下存独立副本，完全不会互相干扰，不需要做任何依赖裁剪，就能保证应用开箱即用。

• 执行py -m build默认不打包Pipfile/Pipfile.lock、pip安装时不识别这两个文件属于正常设计：Pipfile/Pipfile.lock是pipenv专属的开发期依赖锁定文件，不属于Python分发包的标准规范，就算强行通过MANIFEST.in塞进包里，标准pip、其他虚拟环境工具（venv/poetry等）也不会识别，完全没必要做这类修改。
• 入口点找不到虚拟环境依赖的问题本质是解释器路径硬编码：pip生成入口点时，会把当前执行安装操作的Python解释器路径写死在入口点脚本的shebang行里。全局环境下安装生成的入口点必然指向全局Python，自然找不到虚拟环境内的依赖；而虚拟环境内生成的入口点，只要直接调用该脚本文件，哪怕不手动激活虚拟环境，也会自动加载虚拟环境内的依赖——激活虚拟环境的本质只是把虚拟环境的bin目录临时加到当前shell的PATH里，不影响脚本本身的shebang指向。
• pipenv在虚拟环境内安装应用后，入口点不在系统PATH是虚拟环境的默认设计，目的就是避免全局命令冲突，不需要手动给虚拟环境目录加PATH变量，软链接或者绝对路径调用都可以解决。
• pipenv无法读取分发包内嵌入的Pipfile.lock，这个设计本身就不符合Python包规范，不要尝试这类实现。

整个流程不需要将应用打包为标准pip分发包，步骤如下：

1. 开发收尾阶段，在本地开发虚拟环境执行pipenv lock，确认Pipfile.lock内的依赖版本和本地测试通过的版本完全一致，将应用代码、Pipfile、Pipfile.lock共同打包为部署用的普通代码压缩包（不需要执行build命令）。
2. 生产服务器上为每个应用创建独立的部署目录，例如/opt/apps/your_application/，将代码压缩包解压到该目录下。
3. 在部署目录下执行pipenv install --deploy --ignore-pipfile，命令会自动在当前目录下生成专属虚拟环境，严格按照Pipfile.lock记录的版本安装全量依赖，全程不会修改全局Python环境的任何包，和其他应用的虚拟环境完全隔离。
4. 配置启动入口，二选一即可：
   • 直接使用虚拟环境内入口点的绝对路径编写启动命令，通常虚拟环境的bin目录在部署目录下的.venv/bin/路径下，例如/opt/apps/your_application/.venv/bin/your_command，无论当前shell激活的是哪个环境，用绝对路径启动都会自动加载对应虚拟环境的依赖，不会出现环境串扰。如果是配置systemd等进程守护服务，直接写这个绝对路径即可，不需要额外做环境激活操作。
   • 如果需要让应用命令全局可调用，直接在系统PATH包含的目录（比如/usr/local/bin）下创建软链接指向虚拟环境内的入口点即可，例如ln -s /opt/apps/your_application/.venv/bin/your_command /usr/local/bin/your_command，软链接会保留原入口点的shebang指向，启动时自动加载对应虚拟环境的依赖，不会影响其他应用。

如果你开发的是需要分发给其他用户在自有环境安装的通用CLI工具、开源库，才需要执行py -m build打标准分发包。这类场景下不要在包内嵌入Pipfile/Pipfile.lock，只需要在pyproject.toml里写清楚兼容的依赖版本范围即可，用户安装时会自行选择全局安装或虚拟环境隔离安装，依赖版本适配由pip自动处理，不需要在发布侧提前锁定全量依赖版本——全量锁定版本是自主可控服务部署阶段的要求，不是通用包发布的要求。

内容的提问来源于stack exchange，提问作者gemisigo