在应用程序之间共享/管理内部 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 上，它看起来像 BB冻结 是处理这个问题的正确方法。引用主页的内容，它提供：

• zip/egg 文件导入跟踪：bbfreeze 跟踪 zip 文件的导入，如果从 Egg​​ 文件使用某些模块，则包括整个 Egg 文件。使用 setuputils 的 pkg_resources 模块的软件包现在可以工作（0.95.0 中的新增功能）
• 二进制依赖跟踪：bbfreeze 将跟踪二进制依赖性，并将包括冻结程序所需的 DLL 和共享库。

Answer 2

“每次有新库时都针对 App1、2、3 进行显式测试”实际上并不是那么繁重。

两件事情。

• 您需要一套正式的 API 单元测试，库 必须 经过。这只是 API，而不是功能的每一个细微差别。如果这通过了，那么您的更改就可以进行了。如果失败，则说明您的更改破坏了 API。

• 您还需要一组独立于 API 的功能单元测试。这是更大的，并且可能被归类为“繁重”。

一旦开始单元测试，您就会上瘾。一旦您完成了相当完整的测试，这个问题就很容易解决。

Answer 3

我用这个食谱条目的变化来分发Python应用程序。基本上，它涉及到荏苒所有的Python源成一个zip文件，然后用shell脚本相连来导入的源文件。

如果你需要给一个应用程序自身的库的版本，这可能是有帮助的。