符合PEP440的Python预发布/开发/本地版本处理问询

核心问题分析 #

你之前使用的1.0.1post+feature.foo版本号，按照PEP 440规则属于正式版本的补丁更新，优先级高于原始正式版1.0.1，所以pip在匹配==1.0.1时会优先选择这个更高的post版本，同时它也符合~=1.0.1的依赖范围，导致意外安装开发版。

可行解决方法 #

方法1：基于下一个版本的预发布版本号（推荐）

生成开发版本号时，采用[下一个版本号].devN+<分支标识>的格式，比如针对1.0.1的开发分支，版本号设为1.0.2.dev1+feature.foo：

• 满足你的两个版本要求：
  • 1.0.2.dev1+feature.foo > 1.0.1（符合>=已发布最新版）
  • 按照PEP 440规则，预发布版本1.0.2.dev1 < 正式版本1.0.2（符合<下一个版本）
• pip默认不会主动选择预发布版本，只有显式添加--pre参数或指定完整开发版本号时才会安装，彻底避免正式环境意外安装。

验证代码：

python -c "from compatibleversion import check_version; assert check_version('1.0.2.dev1+feature.foo', '>=1.0.1')"

python -c "from compatibleversion import check_version; assert check_version('1.0.2.dev1+feature.foo', '<1.0.2')"

方法2：纯本地版本标识符（仅本地开发场景）

如果开发版本无需推送到共享包源，仅在本地虚拟环境使用，可以用1.0.1+local.<分支标识>的格式：

• +后的内容属于PEP 440的本地版本标识符，不参与版本排序，1.0.1+local.foo和正式版1.0.1被视为同优先级，pip安装==1.0.1时会优先选择正式发布的版本。
• 缺点：如果推送到公共源，这个版本仍可能被pip识别为兼容==1.0.1的版本，适合纯本地开发场景。

方法3：优化测试源隔离方案

保留你当前的测试源隔离方案，同时通过工具自动化源切换：

• 用tox、poetry或pipenv等工具，配置开发环境指向测试源，正式部署环境仅指向生产源。
• 优势：完全隔离开发版和正式版，无意外安装风险，适合团队协作场景。

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