第三方依赖中的Bug造成Python打包困境
我是一个使用 Python 和 PyGTK 的 Linux 软件项目的开发人员。我们正在编写的程序依赖于许多第三方软件包,这些软件包可通过所有市长发行版存储库获得。其中之一是 python 绑定(用 C 编写),它允许我们的程序与通用 C 库聊天。不幸的是,绑定中存在一个错误,对我们的程序影响很大。最近提出了修复/补丁,但尚未提交。我们希望尽快包含此修复程序,但不确定最好的行动方案是什么。
根据我描述的场景,我们认为有以下选择。希望有人能够提供更多见解,或者向我们指出一个我们尚未考虑的解决方案
- 等待 python 绑定更新。 这样做的问题是,我们无法知道更新何时会被分发存储库接受,或者即使它会向后移植到早期
- 版本。 包括 python 绑定的修改版本,包括修复我们的程序并让用户在安装时对其进行编译。 这会给打包者带来负担,因为每个发行版的每个版本都会链接到另一个版本的 C 库。
- 用 C++ 重写我们的程序并避免一起处理 python 绑定。 是的,实际上正在考虑这个呵呵。
- 保持我们现有的丑陋黑客完好无损。 显然不是更好的选择,因为它是一个丑陋的黑客
提前致谢!
I'm a developer on a software project for Linux that uses Python and PyGTK. The program we are writing depends on a number of third-party packages that are available through all mayor distro repositories. One of these is a python binding (written in C) that allows our program to chat with a common C library. Unfortunately, there's a bug in the bindings that affects our program a great deal. A fix/patch was recently presented, but hasn't been committed yet. We want to include this fix as soon as possible, but are unsure that the best course of action would be.
Based on the scenario I described, we figured we have the following options. Hopefully someone can give more insight or maybe point us to a solution we haven't considered yet
- Wait for the python bindings to be updated. The problem with this is that we have no way of knowing when the update would be accepted into distribution repositories, or even if it will be backported to earlier releases.
- Include a modified version of the python bindings including the fix with our program and have users compile it on installation. This would provide a burden for packagers as every version of every distribution would link against another version of the C library.
- Rewrite our program in C++ and avoid dealing with python bindings all together. Yep, actually considering this hehe.
- Keep the ugly hack we have in place intact. Not preferable obviously as it is, well, an ugly hack
Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
只要丑陋的黑客有效,就使用它。它对于你的包来说会有一些缺点。此外,您可以稍后通过要求依赖项的无错误版本来逐步淘汰它(显着),当它被发布并可用一段时间时,以便发行版有机会开始发布它。
As long as the ugly hack works, use it. It will have drawbacks local to your package. Additionally, you can phase it out (significantly) later by requiring a bug-free version of your dependency, when it is released and is available for some time so that distros have a chance to start shipping it.