在應用程序之間共享/管理我們的內部python庫的最佳方式

Question

我們公司（xyz）正在將大量Flash代碼移植到Python中。

在Flash中，我們的Flash應用程序之間有一個共享庫 - 軟件包xyz。我們可以對軟件包進行更改，而不必擔心在部署應用程序時打破其他應用程序，因爲Flash會編譯其代碼幷包含庫的內容。我們通過RPM部署最終的SWF，然後完成。 App1和App2的更新不會中斷App3。

你將如何在Python中共享庫依賴。

App1，App2和App3可能都需要xyz-lib.rpm，並且都使用相同的庫文件，但每次更新xyz-lib.rpm都必須明確測試App1,2,3 有一個新的圖書館，這只是麻煩。

我目前最喜歡的解決方案 - 我可以讓app1.rpm包含打包時的庫 - 有效地實現庫的某種靜態鏈接。然而，這感覺不雅。 （儘管唯一的額外成本是硬盤空間==便宜。）

我知道，共享庫的穩固管理可能是最好的解決方案，但我一直試圖考慮所有的開發人員都是人，犯錯誤。我們會犯錯誤，我不希望部署app1來破解app2和app3 - 測試和調試只是更多。

Answer 1

我也喜歡將所有東西打包在一起並將操作系統庫的依賴限制在最小值（glibc，就是這樣）的解決方案。硬盤很便宜，客戶和支持時間不是。

在windows上，py2exe + InnoSetup是很平常的。

在Linux上，它看起來像bbfreeze是正確的處理方法。從主頁引用，它提供：

• ZIP /蛋文件導入追蹤： bbfreeze跟蹤從zip文件導入包括全蛋的文件，如果某些模塊是從eggfile使用。使用setuputils的pkg_resources模塊的軟件包現在可以工作（0.95.0中的新功能）
• 二進制相關性跟蹤： bbfreeze將跟蹤二進制相關性，並將包括凍結程序所需的DLL和共享庫。

Answer 2

「每次有新圖書館時都會對App1,2,3進行明確測試」實際上並不那麼麻煩。

兩件事。

• 你需要一套正式的API單元測試庫必須通。這只是API，並不是每一個功能的細微差別。如果這通過了，那麼你的改變是很好的。如果失敗，您的更改會破壞API。

• 您還需要一組功能單元測試，與API分開。這是更大的，可能被歸類爲「繁重」。

一旦你開始單元測試，你會上癮。一旦你有相當完整的測試，這個問題很容易管理。

Answer 3

我已經使用此cookbook entry的變體來分發python應用程序。基本上它涉及到將所有Python源代碼壓縮成一個zip文件，然後將其與shell腳本連接以導入源文件。

如果您需要爲應用程序提供其自己的版本的庫，這會很有幫助。