构建：使用系统Python中的依赖项

我正在尝试使用一个Python包，它在使用时依赖于两个扩展模块：和。两个模块都使构建失败：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

其中

foobar

包的

setup.py

包含：

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

在寻找解决方案的过程中，我偶然发现了配方

z3c.recipe.scripts

和它的功能。但是，当应用于my

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系统中，但它似乎没有效果（仍然失败）。删除

允许的鸡蛋..

行时也是如此

我的问题：我的

buildout.cfg

在概念层面上有什么错误吗

---

我知道有一个配方，它使用configure，make，make-install安装鸡蛋。然而，在我的例子中，简单地引用系统Python代码就足够了。我不需要由构建生成的100%可复制环境。此外，dbus python和pygobject默认安装在大多数Linux桌面系统上，这是使用

foobar

的环境。

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

[buildout]
...
versions = versions

[versions]
pygobject = 1.2.3

或者，我所做的是，您可以将旧的1.4.4构建（您需要一个特殊的bootstrap.py，googleit）与结合使用

---

我个人会选择osc.recipe.sysegg解决方案，这是可靠的。

您可能希望对每个表现不佳的python发行版使用CMMI部件，并对

python

部件使用

额外路径

选项，以确保CMMI部件包含在python路径中。

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

---

因此，虽然这些包可以通过PyPI检索，但它们不能用于任何希望Python包以鸡蛋的形式发布的基础设施中。实际上，这意味着对这些包的依赖关系不能在

setup.py

中列出，而需要以其他方式处理（如果有的话）。

我发现最好的方法是将include site packages设置为true，然后使用来欺骗setuptools，使其认为在安装过程中鸡蛋是可用的。唯一的缺点是你无法控制网站包的使用；您可以将站点软件包中允许的鸡蛋设置为空，以停止使用鸡蛋，但所有软件包都将可用。总之，下面是我的构建中的一个片段：

[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

---

sysegg

解决方案通常也适用于buildout 1.5.2。但是，使用

dbuspython

和

pygobject

时，它仍然失败。我没有使用这些模块，而是尝试从系统路径使用一个更简单、更纯粹的Python包，然后它成功了——无论是在我最初的设置中还是在使用sysegg解决方案时。我认为问题在于dbus-python和pygobject在我的系统（ubuntu10.4）上没有作为真正的鸡蛋安装，至少它们没有

egg-info

。构建需要一个

egg info

来识别发行版，这对吗？我真的不懂版本控制。固定版本应该如何说服buildout使用系统Python？版本固定：它确实说服buildout使用系统Python站点包中的包。顺便说一句，我个人不喜欢这种限制性行为，这就是为什么我坚持使用sysegg配方。Egg-info：我认为这是必要的，因为这就是鸡蛋变成鸡蛋的原因。因此是一个真正的包裹。例如，egg信息包含包名（目录可能与包名不同，例如名称“django staticfiles”包含包“django_staticfiles”）。好的，这是有意义的。我愿意接受你的回答，只是为了再次表示感谢。然而，从技术上讲，我自己的答案更符合我最初的问题。我希望你能接受我的荣誉：）是的，从技术上讲，这可能是正确的解决方案。但是，正如我问题的最后所指出的，这对我来说有点过分了。我只是想让buildout忽略一些依赖项。听起来像是一个务实的黑客。我会检查并报告它是否对我的案子有效。

[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