Search code examples
pythondbusbuildoutpygobject

Buildout: use dependencies from system Python


I'm trying to use buildout for a Python package which, when used, depends on 2 extension modules: dbus-python and pygobject. Both modules make buildout fail: dbus-python lacks a setup.py file, while pygobject has one but whose usage is discouraged -- instead configure, make, make install should be used. So, buildout isn't able to setup these dependencies in the development environment.

Here's my buildout.cfg:

[buildout]
develop = .
parts = eggs

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

where setup.py for the foobar package contains:

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

While looking for a solution, I stumbled upon the recipe z3c.recipe.scripts and its ability to utilize system-wide installed eggs. However, when applied to my buildout.cfg ..

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

.. it appears to have no effect (still fails), although both packages (dbus, gobject) are installed in my system Python. The same is true when I remove the allowed-eggs.. line.

My question: Did I got something wrong here on a conceptional level or is there an error in my buildout.cfg?

I know there's zc.recipe.cmmi, a recipe which installs eggs using configure, make, make install. However, simply referencing system Python eggs would be sufficient in my case. I do not need a 100% reproducible environment generated by buildout. Also, dbus-python and pygobject are installed by default on most Linux desktop systems, the environment where foobar is intended to be used.


Solution

  • Thanks to @Rainout's answer and comments I found the actual source of my problem. The problem is not in buildout or my configuration but in the Python bindings for DBus and Gobject: these packages aren't distributed as eggs but as plain packages.

    So while these packages can be retrieved via PyPI, they cannot be used in any infrastructure which expects Python packages to be shipped as eggs. In practice this means that the dependencies to these packages must not be listed in setup.py but need to be handled in some other way (if at all).