Buildout: использовать зависимости от системы Python

Question

Я пытаюсь использовать 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 и его способность использовать общесистемные установленные яйца .Однако, когда он применяется к моему 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 *)1034 *) установлены в моей системе Python.То же самое верно, когда я удаляю строку allowed-eggs...

Мой вопрос: Я ошибся здесь на концептуальном уровне или в моем buildout.cfg есть ошибка?

Я знаю, что есть zc.recipe.cmmi, рецепт, который устанавливает яйца, используя configure, make, make install .Однако в моем случае было бы достаточно просто ссылаться на систему Python egg.Мне не нужна воспроизводимая на 100% среда, созданная buildout.Кроме того, dbus-python и pygobject установлены по умолчанию на большинстве настольных систем Linux, в среде, где foobar предназначено для использования.

Answer 1

Я не получил последние версии 1.5.x для работы с системными пакетами.Есть один способ: закрепить версии.Таким образом, zc.buildout 1.5.x подхватит его.

[buildout]
...
versions = versions

[versions]
pygobject = 1.2.3

В качестве альтернативы, то, что я делаю, вы можете использовать старую сборку 1.4.4 (для этого вам потребуется специальный bootstrap.py, Google это) в сочетании с osc.recipe.sysegg .

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

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

Я бы лично пошел на решение osc.recipe.sysegg, поскольку это надежно.

Answer 2

Возможно, вы захотите использовать часть CMMI для каждого из этих плохих поведений Python и использовать опцию extra-paths для вашей части python, чтобы убедиться, что части CMMI включены в путь Python.

Answer 3

Благодаря ответу и комментариям @ Rainout я нашел фактический источник моей проблемы.Проблема не в сборке или моей конфигурации, а в привязках Python для DBus и Gobject: эти пакеты распространяются не как яйца, а как простые пакеты.

Поэтому, хотя эти пакеты можно получить через PyPI, они не могутиспользоваться в любой инфраструктуре, которая ожидает, что пакеты Python будут отправлены как eggs .На практике это означает, что зависимости от этих пакетов не должны быть перечислены в setup.py, но должны обрабатываться другим способом (если вообще).

Answer 4

Лучший способ сделать это - установить для include-site-packages значение true, а затем использовать рецепт mockedeggs , чтобы заставить 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