Python 中 Bleeding Edge/Nightly Build 依赖管理有哪些策略和最佳实践？

建议使用同一个包名，用符合 PEP 440 的版本号区分稳定版和开发版。普通使用者执行 pip install library，GUI 开发人员通过 --pre 或指定开发版本来选择 nightly build。GUI 的正式交付环境单独锁定依赖。

如果 GUI 声明了 library==1.2，升级到其他版本就会违反它的依赖要求。因此，要让开发人员试用新版本，还需要调整 GUI 的开发环境配置，单独执行 pip install --upgrade library 无法解决这个问题。

1. 用版本后缀表达发布状态

可以保留 X.Y.Z 作为基础版本号，用标准后缀标识开发阶段。以下包名和版本号均为示例：

同一个目标版本内，版本按以下顺序排列：

1.3.0.dev42 < 1.3.0a1 < 1.3.0b1 < 1.3.0rc1 < 1.3.0

每次 nightly 构建都应使用唯一、递增的开发编号，例如 CI 构建序号。不要用同一个版本号反复上传内容不同的包，否则会给缓存处理和环境复现带来麻烦。

如果所有版本都使用没有后缀的 X.Y.Z，pip 就无法区分实验版本。比如，将未经验证的构建发布为 1.3.0，普通使用者也可能升级到它。

hotfix 达到正式发布要求后，才能进入稳定渠道。已验证的代码修复通常递增补丁版本，.postN 不宜用来替代日常代码修复版本。

2. 普通使用者默认安装稳定版

通常，在未开启预发布选项、也未显式要求开发版本时，pip 默认排除预发布版和开发版：

# 首次安装
python -m pip install library

# 更新已安装的包
python -m pip install --upgrade library

这里的“最新”是指当前软件源中可安装的最新兼容版本，受 Python 版本、平台和依赖约束影响。

pip install library 不会因为软件源中出现新版本就自动更新已有安装，更新时需要加上 --upgrade。

默认筛选规则也不会强制环境回到稳定版。如果已经安装了开发版，或者需求中显式包含预发布版本，选择结果可能不同。需要回退到某个版本时，应明确指定：

python -m pip install "library==1.2.1"

3. GUI 开发人员主动选择开发版

要跟进当前可用的较新版本，包括预发布版，可以使用：

python -m pip install --upgrade --pre library

--pre 允许 pip 选择预发布版和开发版。pip 仍会根据版本和约束选择候选版本，因此不保证一定安装 nightly。例如，同一目标版本的正式版发布后，会排在此前的 .devN 之后，成为更高的版本。

要跟进某个开发系列，可以指定范围：

python -m pip install --upgrade --pre \
  "library>=1.3.0.dev0,<1.4"

需要复现问题或验证某次构建时，最好直接指定版本：

python -m pip install "library==1.3.0.dev42"

显式指定这样的开发版本时，通常无需再加 --pre。

--pre 还会影响本次依赖解析中的其他包。如果只想测试某个确定的 library 构建，精确指定版本通常更容易控制安装结果。

4. 解决 GUI 的固定依赖与开发升级之间的冲突

原始配置中的每个依赖都需要单独作为列表元素：

install_requires=[
    "library==1.2",
    "package_x==0.3",
    "package_y==0.6",
]

这个声明要求 GUI 使用 library==1.2。在已有环境中单独升级 library，有时会留下依赖冲突；如果在同一次安装中解析 GUI 和新版 library，则可能直接失败。

具体如何调整，取决于 GUI 实际兼容哪些版本。

声明兼容范围，单独锁定交付版本

如果 GUI 确实兼容某个版本范围，可以在项目元数据中声明。例如，采用 pyproject.toml 的项目可写为：

[project]
name = "gui_tool"
version = "0.8.0"
dependencies = [
    "library>=1.2,<2.0",
]

兼容范围应根据 API 兼容承诺和测试结果确定，不能仅为了让安装成功而放宽。

这样，GUI 开发人员就可以在独立虚拟环境中同时安装 GUI 源码和目标开发版：

python -m pip install -e ./gui_tool "library==1.3.0.dev42"
python -m pip check

pip check 用于检查已安装包的依赖声明是否一致。GUI 能否正确使用新版 API，还需要通过对应的集成测试验证。

正式交付时，再用锁定文件固定经过验证的完整依赖集合。

保留严格固定版本，使用单独的开发配置

如果 GUI 只承诺支持某个精确版本，可以保留 ==。测试新版 library 时，需要在 GUI 的开发分支中更新依赖声明，验证通过后再发布对应的 GUI 版本。

constraints 文件无法覆盖这个要求。例如：

# GUI 的依赖声明
library==1.2.0

# constraints-dev.txt
library==1.3.0.dev42

这两个条件相互冲突。constraints 只能进一步限制候选版本，不能替换项目自身的依赖声明，--pre 也不能绕过 ==。

5. 把兼容性声明与可复现安装分开管理

GUI 的依赖元数据声明软件允许与哪些版本一起运行；发布锁定文件记录本次交付具体安装哪些包和版本。

只固定直接依赖，通常还不足以复现整个环境，因为这些包可能引入未固定的传递依赖。GUI 的正式发布环境应记录完整依赖集合。如果有严格的复现要求，还应记录分发文件哈希，并考虑 Python 版本和平台差异。

可以这样安排：

• library 的元数据声明实际兼容的依赖范围，便于其他项目使用。
• GUI 的开发环境允许试用指定的 library 开发构建。
• GUI 的发布环境使用经过测试的完整锁定文件。

这些配置应纳入版本控制。README 说明安装入口和工作方式即可，无需人工维护当前稳定版的版本号。

6. 同一套 CI 流程可以发布不同渠道

稳定版和 nightly build 可以共用构建、测试和上传流程，按渠道调整触发条件、版本号及必要的发布门槛。例如：

1. 开发分支按计划构建，生成 1.3.0.devN。
2. 稳定分支上的修复先生成 1.2.1.devN，供 GUI 开发人员验证。
3. 正式发布时使用 1.2.1 或 1.3.0，生成对应版本的分发包。
4. 保留版本号与源码提交的对应关系，便于定位和回退。

稳定版和开发版可以放在同一个软件源中，通过版本号和安装参数控制选择。如果团队需要更严格的隔离，也可以分别提供 stable 和 nightly 索引。

使用独立索引时，应明确配置 --index-url 或对应环境的 pip 配置。--extra-index-url 会将多个来源的候选版本放在一起选择，无法表达“优先稳定源，找不到才去开发源”的规则。

7. 联调源码时，显式使用 editable install

开发 library 本身时，可以从本地源码安装：

git clone <library-repository-url> library
python -m pip install -e ./library

之后可以通过 Git 切换分支或提交。如果切换后依赖、构建配置或扩展模块发生变化，需要重新安装或构建。

不建议把克隆仓库、切换分支等操作藏进 GUI 的 setup.py。安装时隐式访问仓库，会额外受到认证、网络条件和源码状态的影响。这些操作应由开发人员显式执行，或交给环境初始化脚本。

日常 GUI 集成使用带唯一版本号的 wheel，更方便复现；同时修改两个项目、进行本地联调时，editable install 更直接。两种方式可以并存，共用同一份源码和版本管理规则。

备注：内容仅供参考。