Azure Pipeline安装依赖出现包版本冲突如何解决

报错本质是Python包的硬版本约束冲突：你在requirements.txt里固定的azure-storage-blob==2.1.0是2019年发布的v2代旧SDK，和你引入的azure-storage-file-datalake 12.7.0的依赖要求完全不匹配——后者明确要求azure-storage-blob版本必须落在>=12.12.0,<13.0.0区间，pip没法同时满足两个完全不重叠的版本范围，直接终止安装。

直接删掉requirements.txt里azure-storage-blob的固定版本标记（把azure-storage-blob==2.1.0改成azure-storage-blob）确实可以让pip自动解析兼容版本、解决当前安装阶段的报错，但有个很容易踩的坑：
pip会自动装符合datalake要求的12.x系列最新版blob SDK，而2.1.0和12.x版本的API是完全断层的——比如旧版常用的BlockBlobService类在12.x里已经被拆成BlobServiceClient等新接口，如果你之前的业务代码是照着2.1.0写的，就算依赖装成了，函数跑起来照样会报方法不存在、导入失败的错，得同步改对应的SDK调用代码。

• 方案1：固定兼容版本区间（生产环境优先选）
  别完全放开版本约束，不然哪天依赖偷偷升大版本很容易出线上问题。直接把requirements.txt里两个相关包的版本改成明确兼容的组合就行：

  # 其余原有依赖保持不变
  azure-storage-blob>=12.12.0,<13.0.0
  azure-storage-file-datalake==12.7.0
  

  改完不用动现有流水线的安装逻辑，直接重跑就过。

• 方案2：降级datalake SDK适配旧版blob
  要是你现有代码强依赖2.1.0版本的blob SDK、改代码成本太高，可以把azure-storage-file-datalake降到12.0.0之前的早期预览版，这部分版本是兼容v2代blob SDK的。但非常不推荐选这个方案：早期datalake SDK缺很多功能，有不少已知bug，官方早就停更了。

• 方案3：用锁文件彻底规避版本解析问题
  本地搭一个和流水线Python版本、系统环境一致的虚拟环境，手动调通所有依赖的兼容版本，本地跑通功能之后执行pip freeze > requirements-lock.txt，把所有依赖的版本都固定死，把这个锁文件提交到代码库。再把流水线里的安装命令改成pip install -r requirements-lock.txt，之后每次流水线装的都是你本地验证过的版本，不会再出现pip自动解析版本导致的冲突，企业级项目基本都这么做。

• 方案4：对齐Azure Function运行时预装依赖
  Azure Function的Python worker本身会预装一批通用Azure SDK包，你可以查下当前用的函数运行时版本自带的azure-storage-blob版本，直接把requirements.txt里的版本和预装版本对齐，既能解决冲突，还能减少冷启动时的依赖下载安装耗时。

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