4

我们公司 (xyz) 正在将我们的大量 Flash 代码迁移到 Python。

在 Flash 中，我们的 Flash 应用程序之间有一个共享库 - 包 xyz。我们可以对包进行更改，而不必担心在部署其他应用程序时会破坏它们，因为 Flash 会编译它们的代码并包含库的内容。我们通过 RPM 部署最终的 SWF，我们就完成了。App1 和 App2 的更新永远不会破坏 App3。

您将如何在共享库依赖项 Python 中处理此问题。

App1、App2 和 App3 都可能需要 xyz-lib.rpm，并且都使用相同的库文件，但是每次有新库时，都必须针对 App1、2、3 显式测试更新的 xyz-lib.rpm ，这只是繁重的。

我目前最喜欢的解决方案——我可以让 app1.rpm 包含打包时的库——实际上是库的某种静态链接。然而，这感觉很不雅。（虽然唯一的额外成本是硬盘空间==便宜。）

我知道共享库的可靠管理可能是最好的解决方案，但我一直在努力考虑到所有开发人员都是人类，并且会犯错误。我们会犯错误，我不希望 app1 的部署破坏 app2 和 app3 - 它只是要测试和调试更多。

4

3 回答 3

4

“每次有一个新库时都针对 App1,2,3 进行明确测试”实际上并没有那么繁重。

两件事情。

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

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

一旦你开始单元测试，你就会上瘾。一旦你合理地完成了测试，这个问题就很容易解决。

于 2008-12-04T23:30:12.170 回答
1

我已经使用这个食谱条目的变体来分发 python 应用程序。基本上它涉及将所有 python 源压缩到一个 zip 文件中，然后将其与 shell 脚本连接以导入源文件。

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

于 2008-12-04T23:34:10.993 回答
1

我也赞成将所有东西打包在一起并将对操作系统库的依赖限制到最小的解决方案（glibc 就是这样）。硬盘便宜，客户和支持时间不便宜。

在 Windows 上，使用 py2exe + InnoSetup 很简单。

在 Linux 上，看起来bbfreeze是处理这个问题的正确方法。引用主页，它提供：

  • zip/egg 文件导入跟踪：bbfreeze 跟踪从 zip 文件的导入，如果从 eggfile 中使用某些模块，则包括整个 egg 文件。使用 setuputils 的 pkg_resources 模块的包现在可以工作（0.95.0 中的新功能）
  • 二进制依赖跟踪：bbfreeze 将跟踪二进制依赖，并将包括冻结程序所需的 DLL 和共享库。
于 2008-12-05T11:41:39.867 回答