如何在不依赖 SCM 的情况下处理 Python 包的开发版本？
Pinax 开发过程中出现的一个问题是处理外部应用程序的开发版本。我正在尝试提出一个不涉及引入版本控制系统的解决方案。原因是我不想在我的系统上安装所有可能的版本控制系统（或强制贡献者这样做）并处理环境创建过程中可能出现的问题。
就拿这个情况来说（了解Pinax的工作原理将有利于理解）：
我们正在开始开发Pinax的新版本。以前的版本有一个 pip 要求文件，其中设置了明确的版本。我们希望解决外部应用程序出现的错误。为了在 Pinax 中修复该错误，当前流程是简单地发布应用程序的次要版本（假设我们拥有该应用程序的控制权）。我们无法控制的应用程序，我们只是处理应用程序作者的发布周期或强制他们发布;-) 我不太喜欢不断地发布小版本来修复错误，因为在某些情况下我希望还致力于应用程序的新功能。当然，我们所做的就是对旧版本进行分支，然后根据需要进行向后移植。
我很想听听对此的一些想法。
One issue that comes up during Pinax development is dealing with development versions of external apps. I am trying to come up with a solution that doesn't involve bringing in the version control systems. Reason being I'd rather not have to install all the possible version control systems on my system (or force that upon contributors) and deal the problems that might arise during environment creation.
Take this situation (knowing how Pinax works will be beneficial to understanding):
We are beginning development on a new version of Pinax. The previous version has a pip requirements file with explicit versions set. A bug comes in for an external app that we'd like to get resolved. To get that bug fix in Pinax the current process is to simply make a minor release of the app assuming we have control of the app. Apps we don't have control we just deal with the release cycle of the app author or force them to make releases ;-) I am not too fond of constantly making minor releases for bug fixes as in some cases I'd like to be working on new features for apps as well. Of course branching the older version is what we do and then do backports as we need.
I'd love to hear some thoughts on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用“==dev”版本说明符来处理这个问题吗？如果 PyPI 上的发行版页面包含指向当前开发版本的 .tgz 的链接（例如 github 和 bitbucket 自动提供），并且您将“#egg=project_name-dev”附加到该链接，则 easy_install 和 pip 都将使用该链接.tgz 如果 ==dev 被请求。
这不允许您固定任何比“最近的提示/头部”更具体的内容，但在很多情况下这可能足够好？
Could you handle this using the "==dev" version specifier? If the distribution's page on PyPI includes a link to a .tgz of the current dev version (such as both github and bitbucket provide automatically) and you append "#egg=project_name-dev" to the link, both easy_install and pip will use that .tgz if ==dev is requested.
This doesn't allow you to pin to anything more specific than "most recent tip/head", but in a lot of cases that might be good enough?
我想说的是，我在询问之前考虑的解决方案是建立一个 Pinax PyPI 并在其上发布开发版本。我们可以举一个 chishop 的实例。我们已经在使用 pip 的 --find-links 来指向 pypi.pinaxproject.com 来获取我们必须自己发布的包。
I meant to mention that the solution I had considered before asking was to put up a Pinax PyPI and make development releases on it. We could put up an instance of chishop. We are already using pip's --find-links to point at pypi.pinaxproject.com for packages we've had to release ourselves.
大多数开源发行商（Debian、Ubuntu、MacPorts 等）都使用某种补丁管理机制。就像这样：导入每个发布的包的基本源代码，作为 tar 球或作为 SCM 快照。然后使用补丁管理器管理任何必要的修改，例如 quilt或 Mercurial 的队列。然后以一致的格式将每个外部包与任何应用的补丁捆绑在一起。或者拥有基本包的 URL 和各个补丁的 URL，并在安装过程中应用它们。这本质上就是 MacPorts 所做的事情。
编辑：要更进一步，您可以对所有外部包中的补丁集进行版本控制，并将其作为一个单元使用。使用 Mercurial 队列可以很容易地做到这一点。然后，您将问题简化为仅使用一个 SCM 系统发布一组补丁，这些补丁如上所述在本地应用，或者可供开发人员提取并应用到他们的基础发行包副本。
Most open source distributors (the Debians, Ubuntu's, MacPorts, et al) use some sort of patch management mechanism. So something like: import the base source code for each package as released, as a tar ball, or as a SCM snapshot. Then manage any necessary modifications on top of it using a patch manager, like quilt or Mercurial's Queues. Then bundle up each external package with any applied patches in a consistent format. Or have URLs to the base packages and URLs to the individual patches and have them applied during installation. That's essentially what MacPorts does.
EDIT: To take it one step further, you could then version control the set of patches across all of the external packages and make that available as a unit. That's quite easy to do with Mercurial Queues. Then you've simplified the problem to just publishing one set of patches using one SCM system, with the patches applied locally as above or available for developers to pull and apply to their copies of the base release packages.
编辑：我不确定我是否正确阅读了您的问题，因此以下内容可能无法直接回答您的问题。
我考虑过但尚未测试的事情是使用 pip 的冻结捆绑功能。也许使用它并与 Pinax 一起分发捆绑包会有效吗？我唯一关心的是如何处理不同的操作系统。例如，我从未在 Windows 上使用过 pip，因此我不知道捆绑包如何在 Windows 上进行交互。
我希望尝试的完整想法是创建一个控制捆绑包管理的摊铺器脚本，使用户可以轻松升级到新版本。但这需要一些脚手架。
另一种选择可能是在一致的 VC 中保留您无法控制的应用程序的镜像，然后分发镜像版本。这将消除“每个人”安装许多不同程序的需要。
除此之外，似乎唯一真正的解决方案就是你们正在做的事情，我找不到一种轻松的方法。
EDIT: I am not sure I am reading your question correctly so the following may not answer your question directly.
Something I've considered, but haven't tested, is using pip's freeze bundle feature. Perhaps using that and distributing the bundle with Pinax would work? My only concern would be how different OS's are handled. For example, I've never used pip on Windows, so I wouldn't know how a bundle would interact there.
The full idea I hope to try is creating a paver script that controls management of the bundles, making it easy for users to upgrade to newer versions. This would require a bit of scaffolding though.
One other option may be you keeping a mirror of the apps you don't control, in a consistent vcs, and then distributing your mirrored versions. This would take away the need for "everyone" to have many different programs installed.
Other than that, it seems the only real solution is what you guys are doing, there isn't a hassle-free way that I've been able to find.