git 分支的 Pip Whl 命名約定

Question

我覺得我做錯了什么。 每當我們推送提交時，我們有一些項目會在 CI 中生成 pip 包。 我正在使用 setuptools_scm 根據最后一個標簽生成版本號。 我有兩個我正在努力解決的問題。

假設我們有兩個開發人員在兩個不同的功能分支中工作的場景。 每當他們中的任何一個提交代碼時，我們的 CI 都會生成一個新的 pip 包並將其推送到開發 pypi 服務器。 該版本包含有關先前標記和提交哈希的信息，但不包含有關生成它的功能分支的任何信息。 如果我查看 pypi 服務器，我會看到來自兩個開發人員的包。 據我所知，如果不付出很大的努力，我就無法分辨出哪些包來自哪個功能分支。

如果有人想測試功能分支，那么他們需要找出 setuptools_scm 生成的確切版本號 - 類似於package-0.1.dev41+gabcdef12 。 每次有人推送一個新的提交時，溝通是很痛苦的。 如果分支名稱是版本的一部分，那就太好了。 （類似於package-0.1.branch.dev41+gabcdef12然后用戶可以執行pip install package==0.1.branch從我的分支獲取最新版本。但我發現這不是有效版本。）

我查看了https://the-hitchhikers-guide-to-packaging.readthedocs.io/en/latest/specification.html及其引用的各種 PEP。 我唯一可以合理放置分支名稱的地方是本地部分。 這將解決第一個問題。 我可以很容易地看到每個包來自哪個功能分支。 但這並不能幫助我測試功能分支。

我知道我可以生成一個 alpha/beta/rc 標簽並使用它。 但這並不符合他們的預期用途。 一個 rc 通常會有來自自上次發布以來合並的許多功能分支的多個提交，而不是功能分支上的每個提交的新 rc。

我知道我不是唯一一個使用 git 和 pip 包的人。 由於我找不到問題的解決方案，我擔心我可能想錯了。 是否有常用或標准化的方法來處理這些問題？

Answer 1

對於將來可能會遇到這種情況的人，我認為最好的解決方案是不打包功能分支。 Pip 允許我們通過pip install git+${REPO_URL}@branch語法從功能分支安裝。 此語法適用於命令行、requirements.txt 文件以及 pip-compile 等工具。 用戶可以將自己綁定到特定分支或特定提交的頭部。

語法不是最容易記住的，但它非常有效地允許我共享一個特性分支。 當我想要發布時，我可以標記 repo 並創建一個更公開消費的包。