actions/runner-images项目中Ubuntu 22.04镜像Python包安装问题分析

问题背景

在使用actions/runner-images项目提供的Ubuntu 22.04镜像时，用户报告了一个关于Python包安装失败的问题。具体表现为当尝试通过pip安装特定版本的mkdocs软件包时，系统报错"ModuleNotFoundError: No module named 'packaging.licenses'"。

问题现象

用户在Azure DevOps流水线中使用ubuntu-latest标签的镜像时，发现不同版本的镜像表现不一致：

1. 使用20250209.1.0版本镜像时，安装过程正常完成
2. 使用20250214.2.0及更新版本镜像时，安装过程失败

错误信息显示在准备元数据(pyproject.toml)阶段，系统无法找到packaging.licenses模块，导致安装过程中断。

根本原因分析

经过深入调查，发现问题与以下几个因素相关：

1. pip版本兼容性问题：系统默认安装的pip 22.0.2版本与某些Python包的构建过程存在兼容性问题。特别是当通过URL直接安装软件包时，这种问题更容易显现。

2. 构建系统依赖：现代Python包构建系统(如hatchling)需要较新的依赖支持，旧版pip无法完全满足这些需求。

3. 安装方式差异：直接通过URL安装软件包与通过PyPI安装的流程有所不同，前者需要完整的构建环境支持。

解决方案

针对这一问题，有以下几种可行的解决方案：

1. 升级pip版本：在执行安装前先升级pip到最新版本(如25.0.1)，可以解决大多数兼容性问题：

   pip install --upgrade pip
   pip install https://github.com/mkdocs/mkdocs/archive/refs/tags/1.6.1.tar.gz
   

2. 使用PyPI安装：如果软件包在PyPI上可用，直接通过包名和版本号安装通常更稳定：

   pip install mkdocs==1.6.1
   

3. 指定镜像版本：如果暂时无法修改安装命令，可以固定使用已知正常的镜像版本(如20250209.1.0)。

技术建议

对于使用actions/runner-images项目的开发者，建议：

1. 在CI/CD流水线中，始终明确指定所需的pip版本，避免依赖系统默认版本。

2. 对于关键依赖，考虑在项目中使用requirements.txt或pyproject.toml文件管理依赖，而不是直接在脚本中安装。

3. 定期更新CI环境中的基础镜像，但要做好测试验证工作。

4. 对于复杂的构建过程，考虑使用虚拟环境隔离系统Python环境。

总结

这一问题展示了Python生态系统中版本兼容性的重要性。随着Python打包标准的演进(pyproject.toml等)，保持构建工具链的更新至关重要。actions/runner-images项目作为CI/CD的基础环境，需要平衡稳定性和新特性支持。开发者在使用时应当了解这些底层依赖关系，并采取适当的预防措施确保构建过程的可靠性。