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

Я пытаюсь использовать buildout для пакета Python, который при использовании зависит от двух модулей расширения: dbuspython и pygobject . Оба модуля делают сбои сборки : dbus-python не имеет файла setup.py , в то время как pygobject имеет один, но использование которого не рекомендуется – вместо этого нужно настроить, сделать, сделать установку . Таким образом, 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 решение, я наткнулся на рецепт 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 ) установлены в моей системе Python. То же самое верно, когда я удаляю строку allowed-eggs..

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

Я знаю, что есть zc.recipe.cmmi , рецепт, который устанавливает яйца, используя configure, make, make install . Тем не менее, простое обращение к системе яиц Python было бы достаточно в моем случае. Мне не нужна 100% воспроизводимая среда, создаваемая buildout. Кроме того, 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, google it) в сочетании с osc.recipe.sysegg .

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

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

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

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

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

Лучший способ, которым я нашел это, – установить 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