如何在不依赖 SCM 的情况下处理 Python 包的开发版本？答案

【问题标题】：How might I handle development versions of Python packages without relying on SCM?如何在不依赖 SCM 的情况下处理 Python 包的开发版本？
【发布时间】：2009-11-10 06:16:31
【问题描述】：

在 Pinax 开发过程中出现的一个问题是处理外部应用程序的开发版本。我正在尝试提出一个不涉及引入版本控制系统的解决方案。原因是我宁愿不必在我的系统上安装所有可能的版本控制系统（或强加给贡献者）并处理环境创建期间可能出现的问题。

以这种情况为例（了解 Pinax 的工作原理将有助于理解）：

我们正在开始开发新版本的 Pinax。以前的版本有一个 pip 要求文件，其中设置了明确的版本。我们希望解决的外部应用程序出现错误。要在 Pinax 中修复该错误，当前流程是简单地制作应用程序的次要版本，假设我们可以控制该应用程序。我们无法控制的应用程序我们只是处理应用程序作者的发布周期或强迫他们发布 ;-) 我不太喜欢不断地发布小版本来修复错误，因为在某些情况下我想成为也在为应用程序开发新功能。当然，分支旧版本是我们所做的，然后根据需要进行反向移植。

我很想听听对此的一些想法。

【问题讨论】：

“我不太喜欢不断地制作小版本来修复错误......” “当然，我们所做的是分支旧版本......” 只是为了清楚，你在说应用程序或 Pinax 本身（或两者）？
我指的是应用程序。然后，我们只需将新的次要版本定位到我们对开发版本的要求中，如果我们希望它在 Pinax 先前版本的次要版本中使用，则将要求向后移植。

标签： python django packaging pinax external-dependencies

【解决方案1】：

您能否使用“==dev”版本说明符来处理这个问题？如果 PyPI 上的发行版页面包含指向当前开发版本的 .tgz 的链接（例如 github 和 bitbucket 都自动提供）并且您将“#egg=project_name-dev”附加到该链接，easy_install 和 pip 都将使用该链接.tgz 如果 ==dev 被请求。

这不允许您锁定比“最近的提示/头”更具体的内容，但在很多情况下可能就足够了？

【讨论】：

【解决方案2】：

我的意思是说，我在询问之前考虑过的解决方案是建立一个 Pinax PyPI 并在其上发布开发版本。我们可以建立一个 chishop 的实例。我们已经使用 pip 的 --find-links 指向 pypi.pinaxproject.com 来获取我们必须自己发布的包。

【讨论】：

不确定 -1 来自哪里，有人愿意解释一下吗？对我来说，这似乎是最好的选择，因为它比我在回答中提到的 ==dev 提供了更多的控制权。

【解决方案3】：

大多数开源发行商（Debian、Ubuntu、MacPorts 等）都使用某种补丁管理机制。就像这样：导入每个已发布的包的基本源代码、tar 球或 SCM 快照。然后使用补丁管理器管理任何必要的修改，例如quilt 或Mercurial's Queues。然后以一致的格式将每个外部包与任何应用的补丁捆绑在一起。或者拥有基础包的 URL 和各个补丁的 URL，并在安装期间应用它们。这基本上就是 MacPorts 所做的。

编辑：更进一步，您可以对所有外部包的补丁集进行版本控制，并使 that 作为一个单元可用。使用 Mercurial Queues 很容易做到这一点。然后，您将问题简化为仅使用一个 SCM 系统发布一组补丁，这些补丁如上所述在本地应用，或者可供开发人员提取并应用到他们的基本发布包副本。

【讨论】：

【解决方案4】：

编辑：我不确定我是否正确阅读了您的问题，因此以下内容可能无法直接回答您的问题。

我考虑过但尚未测试的东西是使用 pip 的冻结捆绑功能。也许使用它并使用 Pinax 分发捆绑包会起作用？我唯一关心的是如何处理不同的操作系统。例如，我从来没有在 Windows 上使用过 pip，所以我不知道 bundle 会如何在那里交互。

我希望尝试的完整想法是创建一个控制捆绑包管理的 paver 脚本，使用户可以轻松升级到新版本。不过，这需要一些脚手架。

另一种选择可能是您在一致的 vcs 中保留您无法控制的应用程序的镜像，然后分发您的镜像版本。这将消除“每个人”安装许多不同程序的需要。

除此之外，似乎唯一真正的解决方案就是你们正在做的事情，我找不到一种无忧无虑的方法。

【讨论】：

这与 Pinax 的发布过程更相关。我们现在有一个非常完善的系统。但是，我们已经考虑尝试使用 pip 的捆绑包进行发布。它仍然在桌面上，但我们还没有做出任何决定朝着那个方向发展。特别是因为 pip bundle 是一个非常实验性的功能。
是的，在重读你的问题后，我发现我没有直接回答。