@SmiteChow 考虑跨平台还是不太合适，现在的一个交付镜像就得两个过 g 大小。

@SunDoge 目前就有 conda 、pypi 混用的情况，有些库 pypi 装起来不是缺这个就是缺那个，然后就直接用 conda 装了。

@Hopetree 是的，我们的项目就是模型平台，会有数据分析和建模场景，不少库需要编译。客户环境也不统一，有 arm 的有 x86 的，还有的会有信创要求。

@moudy 目前是基于基础镜像在工程的 Dockerfile 中打补丁。

@BingoW 之前公司内网的开发、测试、试用环境就是类似方法，直接压缩 miniforge 的 env 下对应工程的虚拟环境进行迁移。后来让我全部改成容器化部署了，省去了很多工作量。测试基于镜像测试，交付时直接交付镜像文件。

还有种方式就是用脚本去逐个安装 requirements.txt 中的库了，绕过-r 的冲突检查。冲突的库单独装只会有 warnning ，但不会终止安装，最后再扫一遍版本。

@Mithril 我们确实没这么严格的流程，但是很赞，mark 。

@JoeJoeJoe 默认行为：pip 会安装满足条件的最新版本，比如某个三方依赖的子依赖要求是> 1.0 ，这个子依赖当时的最新版本是 1.5 ，当时安装的会是 1.5 ，过一段时间这个子依赖的版本迭代到到了 1.7 ，在这时它会安装 1.7 ，这个好解决，在 requirements.txt 中强制子依赖==1.5 ，但因为项目迭代比较久了，后续有人增加或修改了某些依赖，这个操作是直接在环境中单独安装的（这时候不会暴露冲突问题），然后归档依赖版本到 requirements.txt ，但是项目就是在这样的冲突下稳定运行的，时间久了你想在其他服务器复现环境再通过 requirements.txt 构建的时候就会发现有的包有版本冲突，这时候冲突的依赖只能单独安装，然后刷一遍版本。

@iorilu 目前就是这样的，运行环境打包成基础镜像，交付打包时再将混淆的工程打包进镜像。但是遇到不允许容器化部署的客户就比较麻烦了，要根据客户的环境做离线包，客户是金融、银行之类的基本都没有公网。

@killva4624 全指定了版本号的，清单是从当前稳定运行的环境中 pip list --format=freeze 拉下来的，
后续就是想通过这个清单复现环境，但是有些包会出现版本冲突或者构建下来的环境和清单不一致。

@JoeJoeJoe 所以暂时的方法是打成了基础镜像。

@blackshadow 还有就是项目是在某些版本冲突下稳定运行的，-r 构建就会报错退出，只能先注释掉冲突的包，最后在单独 install

@JoeJoeJoe 没准过几个月 pip install -r 下来发现有些包就不一样了😂

@dzdh 用 ai 对比了 uv 和 pixi ，ai 指出 uv 对需要二进制编译的包支持不太友好，项目中算法和机器学习库不少，最近在尝试 pixi ，仍遇到安装环境出现版本冲突的问题，可能 toml 没有编排好的问题。后边准备尝试下 uv ，验证下 ai 的结论。

@JoeJoeJoe 虚拟环境是有的，目前用的 miniforge ，主要是环境复现的问题，最近在尝试 pixi

后面会有 NPU ，DCU 吗？

换 pixi 试试

吃中药用吸管，药液直达嗓子眼，能减少很多不适

@zhangkai1024 miniconda 或者 miniforge 吧，uv 对二进制包不太方便。