Buildout：使用来自系统 Python 的依赖项答案

【问题标题】：Buildout: use dependencies from system PythonBuildout：使用来自系统 Python 的依赖项
【发布时间】：2011-11-06 07:50:25
【问题描述】：

我正在尝试将 buildout 用于 Python 包，该包在使用时依赖于 2 个扩展模块：dbus-python 和 pygobject。两个模块都使构建失败：dbus-python 缺少一个 setup.py 文件，而 pygobject 有一个但不鼓励使用 -- 取而代之的是 configure, make, make install应该使用。因此，buildout 无法在开发环境中设置这些依赖项。

这是我的buildout.cfg：

[buildout]
develop = .
parts = eggs

[python]
recipe = zc.recipe.eggs
interpreter = python
eggs = foobar

setup.py 包中的foobar 包含：

install_requires=['dbus-python', 'pygobject'],

在寻找解决方案时，我偶然发现了配方 z3c.recipe.scripts 及其 ability to utilize system-wide installed eggs。但是，当应用于我的buildout.cfg ..

[python]
recipe = z3c.recipe.scripts
include-site-packages = true
allowed-eggs-from-site-packages = pygobject, dbus-python
interpreter = python
eggs = foobar

.. 它似乎没有任何效果（仍然失败），尽管两个包（dbus、gobject）都安装在我的系统 Python 中。当我删除 allowed-eggs.. 行时也是如此。

我的问题：我在概念层面上是否有什么问题，还是我的buildout.cfg 有错误？

我知道有zc.recipe.cmmi，这是一个使用configure、make、make install安装鸡蛋的配方。但是，在我的情况下，简单地引用系统 Python 鸡蛋就足够了。我不需要由 buildout 生成的 100% 可重现的环境。另外，dbus-python 和 pygobject 默认安装在大多数 Linux 桌面系统上，即打算使用 foobar 的环境。

【问题讨论】：

标签： python dbus buildout pygobject

【解决方案1】：

我还没有获得最新的 1.5.x 构建版本来处理系统包。有一种方法：固定版本。这样，zc.buildout 1.5.x 就会把它捡起来。

[buildout]
...
versions = versions

[versions]
pygobject = 1.2.3

或者，我所做的，您可以将旧的 1.4.4 构建（您需要一个特殊的 bootstrap.py，谷歌它）与 osc.recipe.sysegg 结合使用。

[buildout]
...
parts = 
    ...
    sysegg

[sysegg]
recipe = osc.recipe.sysegg
force-sysegg = true 
eggs =
    dbus-python
    pygobject

我个人会选择 osc.recipe.sysegg 解决方案，因为它很可靠。

【讨论】：

sysegg 解决方案通常似乎也适用于 buildout 1.5.2。但是，dbus-python 和 pygobject 仍然失败。除了这些模块，我尝试使用系统路径中更简单、更纯的 Python 包，然后它就可以工作了——无论是在我的原始设置中还是在使用您的 sysegg 解决方案时。我认为问题在于 dbus-python 和 pygobject 没有作为真正的鸡蛋安装在我的系统（Ubuntu 10.4）上，至少它们没有egg-info。 buildout 是否需要 egg-info 来识别分布？
我真的不明白版本控制的事情。固定版本应该如何说服 buildout 使用系统 Python？
版本固定：它确实说服 buildout 从系统 python 的站点包中使用该包。我个人不喜欢这种限制性行为，顺便说一句，这就是我坚持使用 sysegg 配方的原因。
鸡蛋信息：我认为这是必要的，因为这就是让鸡蛋成为鸡蛋的原因。因此是一个真正的包裹。例如，egg-info 包含包名（目录可能与包名不同，例如名称“django-staticfiles”有一个包“django_staticfiles”）。
好的，有道理。我想接受你的回答，只是再一次说声谢谢。但是，从技术上讲，我自己的答案更适合我原来的问题。我希望你接受我的虚拟荣誉:)

【解决方案2】：

您可能希望为每个表现不佳的 python 发行版使用 CMMI 部分，并为您的 python 部分使用 extra-paths 选项以确保 CMMI 部分包含在 python 路径中。

【讨论】：

是的，从技术上讲，这可能是正确的解决方案。但是，正如我的问题末尾所指出的那样，这对我的使用来说有点过分了。我只是想让 buildout 忽略一些依赖项。

【解决方案3】：

感谢@Rainout 的回答和 cmets，我找到了问题的实际根源。问题不在于构建或我的配置，而在于 DBus 和 Gobject 的 Python 绑定：这些包不是作为鸡蛋分发的，而是作为普通包分发的。

因此，虽然可以通过 PyPI 检索这些包，但它们不能用于任何期望 Python 包以 eggs 形式提供的基础设施。在实践中，这意味着这些包的依赖项不能在setup.py 中列出，而是需要以其他方式处理（如果有的话）。

【讨论】：

【解决方案4】：

我发现最好的方法是将 include-site-packages 设置为 true，然后使用 mockedeggs recipe 来欺骗 setuptools 认为在安装期间可以使用鸡蛋。唯一的缺点是您无法控制站点包中使用的内容。您可以将 allowed-eggs-from-site-packages 设置为空白以停止使用鸡蛋，但所有软件包都可用。无论如何，这是我的构建中的一个 sn-p：

[buildout]
parts =
    mockedeggs
    myapp

include-site-packages = true
allowed-eggs-from-site-packages =

[myapp]
recipe = z3c.recipe.scripts
eggs = ${buildout:eggs}

[mockedeggs]
recipe = collective.recipe.mockedeggs
mocked-eggs =
    mapnik2 = 2.0

【讨论】：

听起来像是一个实用的 hack。我会检查它并报告它是否适用于我的情况。