如何在setup.py中为install_requires依赖设置合理版本边界？

核心逻辑先讲清楚：install_requires的版本约束从来不是要求你在项目初始化阶段就100%摸准所有依赖的兼容边界，本质是做「渐进式的兼容范围声明」，完全不需要靠全量暴力测试提前摸完所有版本的兼容情况，按下面的分层方案做，能把工作量压到原来的十分之一都不到：

• 先搭基础约束框架，拒绝无意义的前置测试
  初始写约束的时候，根本不需要往前翻每个依赖的历史版本测兼容性：
  • 对社区公认严格遵循语义化版本的成熟依赖，直接按你本地开发时正常跑通的版本写下限，上限卡到下一个大版本即可，比如本地开发用的是requests 2.28.0，就写requests>=2.28.0,<3。语义化版本规范约定只有大版本更新会引入不兼容变更，这个约束已经能挡住绝大多数依赖发版导致的安装崩溃问题。
  • 对0.x版本的早期库、历史上多次出现小版本/补丁版本更崩的不规范依赖，把上限收窄到你本地验证过的最新次版本即可，比如pydantic>=1.10.0,<1.11。
    真有用户需要兼容更老的依赖版本，自然会提issue反馈，你到时候再调整下限完全来得及，没必要提前做无用功。
• 用自动化流程替代手动测试摸边界
  不要手动挨个降版本测兼容性，直接在CI流程里加两个常规任务：
  1. 最低版本兼容测试：安装所有依赖满足你写的约束的最低可用版本，跑全量单元测试，跑挂了就把对应依赖的下限往上调到能跑通的版本，整个过程全自动执行，不需要人工干预。
  2. 最新版本兼容测试：安装所有依赖的最新发布版本，跑全量测试，如果挂了就说明依赖要么出了不兼容变更、要么有bug，要么临时把上限卡到上一个正常版本，要么适配新版本改代码。
     这套流程跑下来，你根本不需要特意花时间测版本边界，每次代码提交自动就把边界校准了。
• 搞懂文件定位，不要用错场景
  很多人踩坑都是搞混了两类依赖文件的作用：
  install_requires是给库开发者准备的抽象依赖声明，面向的是下游用户，本来就不该写死精确版本，不然会平白制造大量依赖冲突；如果你是开发可部署的应用、或者要保证自己发布的包在某段时间内安装100%成功，直接用pip-tools或者poetry生成全量版本锁死的锁文件，部署/发布安装的时候走锁文件，根本不会受依赖上游发新版本的影响。
• 停更项目的风险兜底非常简单
  要是你确定项目后续不再维护，怕上游依赖不按规则发版搞崩安装，只需要在最后一次发布前，把所有依赖的上限卡到你当时测试通过的最新版本就行，整个操作10分钟就能搞定，完全不需要提前花大量时间做准备。

两个极端操作一定要避开：一是上来就把所有依赖写死精确版本（比如requests==2.28.1），会给下游用户造成严重的依赖冲突；二是完全不写版本上限，等于把你项目的安装成功率完全交到上游依赖开发者手里，遇到不遵守语义化的库分分钟装崩。

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