在应用程序之间共享/管理我们的内部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脚本连接以导入源文件。

如果您需要为应用程序提供其自己的版本的库，这会很有帮助。