同一项目中部分开发用pipenv虚拟环境、部分用conda虚拟环境是否可行？

以下两种方案可以同时满足不同成员的工具使用习惯，且完全不会互相干扰配置：

方案1：pipenv对接已有conda虚拟环境（保留conda使用习惯+Pipfile依赖管理） #

适合不想放弃conda虚拟环境，同时愿意用pipenv做依赖操作的开发者：

• 本地自行创建并激活目标conda虚拟环境，示例命令：

  conda create -n 自定义环境名 python=对应版本
  conda activate 自定义环境名
  

• 本地配置pipenv环境变量，让pipenv优先使用当前激活的conda环境，不自动创建新虚拟环境：
  • 临时生效（每次执行pipenv前运行）：export PIPENV_IGNORE_VIRTUALENVS=0（Windows cmd执行set PIPENV_IGNORE_VIRTUALENVS=0）
  • 永久生效：将上述命令写入自己的~/.bashrc/~/.zshrc等shell配置文件，仅对本地环境生效，不会影响项目其他成员
• 后续在项目根目录执行pipenv install即可将Pipfile声明的依赖全部安装到当前激活的conda环境中，依赖版本完全对齐Pipfile.lock的统一规范。你平时用conda安装二进制依赖（如CUDA、MKL优化版数值库）的操作也完全不受影响。

方案2：conda直接解析Pipfile（无需安装pipenv） #

适合只想用conda完成所有操作的开发者：

• 本地conda环境先安装Pipfile解析插件：conda install -c conda-forge conda-pipfile
• 进入项目根目录后执行conda install --pipfile，conda会自动读取当前目录的Pipfile完成依赖安装，conda源中不存在的包会自动调用pip从PyPI拉取，完全兼容Pipfile的依赖声明。

项目统一配置规则（避免成员配置冲突） #

• 项目仓库仅提交Pipfile和Pipfile.lock作为唯一的依赖规范文件，不要提交environment.yml、requirements.txt等其他依赖配置文件，避免多份配置不同步
• 将.venv、本地临时生成的environment.yml、requirements.txt加入.gitignore，避免本地私有配置提交到仓库
• 所有成员新增依赖时统一通过pipenv install 包名操作更新Pipfile/Pipfile.lock后提交，保证所有成员的依赖版本对齐

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