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