本文详解如何避免在 environment.yml 和 meta.yaml 中重复声明依赖，通过职责分离（构建/运行/开发）实现单一可信源，并给出可复用的实践方案。
本文详解如何避免在 `environment.yml` 和 `meta.yaml` 中重复声明依赖，通过职责分离（构建/运行/开发）实现单一可信源，并给出可复用的实践方案。
在 conda 生态中，environment.yml 与 meta.yaml 承担不同但易被混淆的职责：前者用于可复现的开发环境（含工具链、测试库、Jupyter 等），后者用于可复现的包构建与运行时依赖（即最终用户安装后实际需要的最小依赖集）。二者本不应“同步”或“复制”，而应按语义分层设计。
✅ 正确分工如下：
- environment.yml：定义完整开发工作流所需的一切——Python 版本、构建工具（如 mamba）、测试框架（pytest, pytest-cov）、文档工具（sphinx）、IDE 支持（ipykernel）等。它面向开发者，强调便利性与一致性。
- meta.yaml：仅声明构建期依赖（requirements: build:）和运行时依赖（requirements: run:）。前者是编译/打包必需的工具（如 gcc, rustc, ninja），后者是用户 conda install your-package 后必须存在的最小依赖（如 numpy, requests），不包含任何开发专用包。
例如，一个需编译 C++ 扩展并依赖 jellyfish 的 Python 包，其 meta.yaml 应精简为：
requirements:
build:
- gcc # 或 m2w64-toolchain (Windows), clang_osx-64 (macOS)
run:
- python >=3.8
- jellyfish >=0.9.0
⚠️ 注意事项：
- ❌ 不要在 meta.yaml 中写 pytest、black、pre-commit 等——它们属于开发环境，应保留在 environment.yml 中；
- ✅ 若多个包共享同一组运行时依赖，可将公共依赖提取为 requirements-run.txt，再通过 pip install -r requirements-run.txt 在 build.sh/bld.bat 中注入（适用于复杂场景）；
- ? environment.yml 可通过 conda env create --file environment.yml --name mydev 快速重建开发环境；conda-build . 则严格依据 meta.yaml 构建隔离的构建环境，二者互不干扰；
- ? 发布到 conda-forge 时，CI 仅读取 meta.yaml，因此其 run 部分必须准确、精简、无冗余——这是用户安装体验与包可靠性的关键。
总结：没有“统一单源”的必要，只有“语义清晰的双源”。environment.yml 是你的开发沙盒，meta.yaml 是你的包契约。保持二者职责分明，反而提升可维护性与可审计性。若仍希望减少手动维护，可借助脚本自动生成 meta.yaml 的 run 段（例如解析 setup.py 或 pyproject.toml 中的 install_requires），但切勿反向操作——meta.yaml 绝不能成为开发环境的源头。
