如何让Dependabot在执行Pipenv lock过程中跳过需要系统依赖的包？

我完全懂你这种挫败感——Dependabot本来是帮你省心更包的，结果因为GDAL这种依赖系统库的包卡住，整个更新流程慢得离谱甚至直接失败，太闹心了。结合你的情况，给你几个实用的解决思路：

方法一：在Pipfile中标记该包跳过lock解析 #

Pipenv本身支持给单个包设置skip-lock属性，这样执行pipenv lock时会直接跳过这个包的依赖解析和lock条目生成，Dependabot自然也就不会在这个包上卡住了。

修改你的Pipfile，给gdal条目加上skip-lock = true：

[packages]
gdal = {version = "~=3.6.2", skip-lock = true}

注意事项： #

• 修改后Pipfile.lock里不会出现gdal的相关记录，团队成员本地部署时需要手动处理gdal的安装（比如先在系统层面安装libgdal-dev这类依赖，再通过pip install gdal~=3.6.2安装）。
• 如果项目依赖gdal的其他子依赖，这个方法可能会导致lockfile里缺少这些依赖，需要确保它们已经被其他包覆盖，或者手动添加到Pipfile中。

方法二：给Dependabot配置前置命令安装系统依赖 #

既然问题根源是Dependabot的运行环境缺少GDAL的系统依赖，那直接在Dependabot执行更新前帮它装上这些依赖就行。Dependabot的pip更新环境基于Ubuntu，你可以在dependabot.yml里添加before_install步骤来安装所需的系统库：

修改你的dependabot.yml：

version: 2
updates:
- package-ecosystem: pip
  directory: "/"
  schedule:
    interval: daily
    time: "04:00"
  open-pull-requests-limit: 10
  allow:
  - dependency-type: direct
  - dependency-type: indirect
  before_install:
    - sudo apt-get update && sudo apt-get install -y libgdal-dev gdal-bin

这个方法的好处是不需要修改Pipfile结构，Dependabot能正常完成lock过程，还能帮你更新gdal的版本（如果有可用更新的话），直接解决根源问题。

方法三：结合锁版本和保留现有lock条目 #

如果你不想修改Pipfile也不想装系统依赖，可以尝试用pipenv lock --keep-outdated命令让Dependabot保留lockfile中已有的gdal条目，而不是重新解析它。需要在Dependabot的配置中自定义lock命令：

在dependabot.yml里添加command选项：

version: 2
updates:
- package-ecosystem: pip
  directory: "/"
  schedule:
    interval: daily
    time: "04:00"
  open-pull-requests-limit: 10
  allow:
  - dependency-type: direct
  - dependency-type: indirect
  command: "lock --keep-outdated"

这个方法的局限性是Dependabot不会帮你更新gdal的版本了，但至少能正常处理其他包的更新，不会卡在lock步骤上。

你可以根据项目需求选择最适合的方法，优先推荐方法二，直接解决系统依赖缺失的问题，让Dependabot恢复正常工作！

备注：内容来源于stack exchange，提问作者BlackLotus