Conda收集包元数据阶段的执行逻辑与耗时排查方法

问题1：Conda 收集包元数据阶段的执行逻辑 #

该阶段不只是拉取environment.yml中所列包的依赖，完整执行流程如下：

• 读取本地.condarc配置中所有启用的软件源（channel），遍历所有匹配当前系统架构的源地址
• 针对每个源拉取对应架构的repodata.json文件，该文件存储了当前源下所有公开可用包的全量信息，包括所有版本号、依赖约束、系统兼容性要求、哈希校验值等，并非仅拉取你指定包的相关数据
• 对比拉取到的元数据和本地缓存的元数据版本，无更新则直接复用本地缓存，有更新则刷新本地缓存文件
• 合并所有源的元数据，去重后构建统一的全局包索引，为后续依赖求解阶段提供计算基础

问题2：定位拖慢元数据收集流程的包的方法 #

可通过以下三种方式快速定位问题包：

• 开启调试日志运行创建命令：执行conda env create -vv -f environment.yml，-vv参数会输出全链路执行日志，日志中会标注每个源的拉取耗时、每个包元数据的处理时间戳，直接查找耗时最长的节点对应的包名即可
• 二分法拆分排查：将environment.yml中的依赖列表拆分为数量相近的两组，分别用两组依赖创建测试环境，哪一组的元数据收集耗时明显更高，就继续拆分该组的依赖，重复3-5次即可快速定位到问题包
• 优先排查特殊依赖：如果你的依赖列表中包含指定自定义源的包、无版本约束的包、需要跨架构兼容的包，这类包通常需要额外拉取多份元数据做兼容性校验，大概率是拖慢流程的诱因

若所有源的元数据拉取整体耗时都很高，优先排查是否使用了海外官方源，替换为国内镜像源即可大幅降低拉取耗时，不属于单个包的问题。

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