我有一个build_requirments_file.py文件，用来给指定Python程序生成requirements.txt，但目前生成的内容是这样的：

huggingface_hub==当前安装版本\
pynput==当前安装版本\
module==当前版本

我想知道怎么确定代码/程序兼容的版本范围，生成类似这样的依赖声明：

huggingface_hub>=x.x.x

或者

pynput<=x.x.x

或者

pynput>x.x.x,<y.y.y （意思是大于x.x.x但小于y.y.y）

通常得安装测试所有依赖版本，但我不想做大量测试，作为单人开发者该怎么解决？

1. 从依赖包的变更日志找关键节点 #

• 先定位你当前使用的依赖版本，去它的GitHub仓库或PyPI页面找CHANGELOG（变更日志），重点盯标注「Breaking Changes」（破坏性变更）的版本。比如你当前用huggingface_hub==0.15.1，如果日志显示0.16.0修改了你代码用到的API，那直接把依赖范围设为huggingface_hub>=0.15.1,<0.16.0。
• 不用通读全部日志，只看你代码实际用到的功能对应的变更记录就行——比如你只用了模型下载功能，就只关注下载相关的更新。

2. 靠语义化版本规则快速推断 #

• 多数Python包遵循语义化版本（SemVer）：格式为主版本号.次版本号.修订号
  • 主版本号升级：基本带破坏性变更，依赖范围可以设为<下一个主版本号，比如当前用2.3.4，就写>=2.3.4,<3.0.0
  • 次版本号升级：一般是新增功能，不会破坏现有代码，可设为>=当前次版本号，比如>=2.3.0
  • 修订号升级：仅修复bug，完全兼容，直接写>=当前版本即可
• 例外提醒：像pandas这类数据科学库，次版本升级可能也有小兼容性问题，这时候结合变更日志确认就行。

3. 做最小范围的关键版本测试 #

• 不用测所有版本，只挑几个关键节点快速验证：
  • 装当前版本的前1-2个次版本，比如当前用pynput==1.7.6，装1.7.0和1.6.8跑一遍核心功能，没问题就设>=1.6.8
  • 如果某个旧版本跑起来报错，就把最低版本设为报错版本的下一个修订版
• 还可以装下一个主版本的beta版，快速验证会不会直接崩，能提前规避大版本兼容问题。

4. 先宽松声明，后续按需收窄 #

• 单人开发精力有限的话，先写宽松的范围，比如huggingface_hub>=当前版本，同时在项目README里标注「推荐使用测试过的版本xxx」
• 如果之后有用户反馈兼容性问题，再把范围收窄——比如发现0.17.0不兼容，就改成>=0.15.1,<0.17.0

5. 特殊依赖的特殊处理 #

• 针对和Python版本绑定的包，比如pynput在Python 3.10以上才支持某些功能，可以结合版本写：pynput>=1.8.0; python_version>="3.10"
• 如果你的代码只用了依赖的基础功能（比如requests发GET请求），直接写requests>=2.0.0就行，基础功能通常不会轻易变更

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