Pinax开发期间出现的一个问题是处理外部应用程序的开发版本。我试图想出一个不涉及引入版本控制系统的解决方案。理由是我宁愿不必在我的系统上安装所有可能的版本控制系统（或强制贡献者），并处理环境创建过程中可能出现的问题。如何在不依赖SCM的情况下处理Python包的开发版本？
把这个情况（知道Pinax如何工作将是有益的理解）：
我们正在Pinax的新版本开始发展。以前的版本有一个带显式版本集的点子需求文件。我们想要解决的外部应用程序出现了一个错误。为了在Pinax中获得该错误修复，目前的流程就是假设我们已经控制了该应用程序，只需制作一个次要版本的应用程序即可。我们没有控制权的应用程序，我们只是处理应用程序作者的发布周期或强制他们发布;-)我不太喜欢不断地为错误修复制作次要版本，因为在某些情况下，我希望成为也在为应用程序开发新功能。当然，分支旧版本就是我们所做的，然后根据需要进行后端操作。
我很想听听这方面的一些想法。
我的意思是说我以前考虑的解决方案是建立一个Pinax PyPI并在其上开发发行版。我们可以举一个chishop的例子。我们已经在使用pip的 - find-links来指向pypi.pinaxproject.com，因为我们必须发布自己的软件包。
不知道-1来自哪里，有人关心解释吗？对我来说，这似乎是潜在的最佳选择，因为它比我在答案中提到的== dev事物提供了更多的控制。 – 2009-11-10 07:46:47
你可以使用“== dev”版本说明符来处理这个吗？如果PyPI上的发布页面包含指向当前开发版本的.tgz的链接（例如github和bitbucket自动提供），并且在链接中追加“＃egg = project_name-dev”，easy_install和pip都将使用该页面.tgz if == dev请求。
这不允许你固定任何比“最近的提示/头”更具体的东西，但在很多情况下可能足够好？
大多数开源代理商（Debian，Ubuntu's，MacPorts等）都使用某种补丁管理机制。所以像这样：导入发布的每个包的基本源代码，作为焦点球或SCM快照。然后使用补丁管理器在其上管理任何必要的修改，如quilt或Mercurial's Queues。然后将每个外部软件包与任何应用的修补程序以一致的格式进行捆绑。或者拥有指向各个修补程序的基本软件包和URL的URL，并在安装过程中应用它们。这基本上就是MacPorts所做的。
编辑：更进一步，您可以控制所有外部软件包中的修补程序集，并使以为单位可用。这对于Mercurial队列来说很简单。然后，您将问题简化为仅使用一个SCM系统发布一组修补程序，其中这些修补程序在上面本地应用，或者供开发人员提供并应用到其基本发行包的副本。
编辑：我不知道我正确阅读你的问题，所以下面可能不会直接回答你的问题。
我已经考虑过但尚未测试过的东西是使用pip的冻结包功能。也许使用它并将Pinax分发包可能会起作用？我唯一担心的是如何处理不同的操作系统。例如，我从来没有在Windows上使用过PIP，所以我不知道一个软件包会如何与之交互。
我希望尝试的完整想法是创建控制捆绑管理的摊铺机脚本，使用户可以轻松升级到更新的版本。这需要一些脚手架。
另一个选择可能是让您不能控制的应用程序的镜像保持一致的vcs，然后分发您的镜像版本。这将消除“大家”对安装许多不同程序的需求。
除此之外，它似乎是唯一真正的解决方案是你们在做什么，没有一种无忧无虑的方式，我已经能够找到。
这将与Pinax的发布过程更相关。我们现在有一个非常完善的系统。但是，我们已经考虑尝试使用pip捆绑发布。它仍在桌面上，但我们还没有做出任何决定。特别是因为pip包是一个非常实验性的功能。 – 2009-11-10 07:42:32
是的，重读你的问题后，我看到我没有直接回答。 – 2009-11-10 08:02:22
“我不是太喜欢，以便修补漏洞不断取得次要版本的...” “当然分支的旧版本是我们做什么......” 只是要清楚，你在说什么的应用程序或Pinax本身（或两者）？ – 2009-11-10 06:38:47
我指的是应用程序。然后，我们只需将我们对dev版本的新要求发布到新版本中，并将需求恢复到以前版本的Pinax的次要版本。 – 2009-11-10 06:45:30