Оборудование: зависимости от использования системы питон

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

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

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

4 3
python buildout

4 ответа:

Я не получил последнюю версию 1.5.X buildouts для работы с системными пакетами тоже. Есть один способ: закрепить версии. Вот так, Зи-Си.постройка 1.5.Икс возьмет трубку.

[buildout]
...
versions = versions

[versions]
pygobject = 1.2.3

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

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

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

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

3

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

2

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

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

Лучший способ, который я нашел, это установить include-site-packages в true, а затем использовать рецептmockedeggs , чтобы обмануть setuptools, думая, что яйца доступны во время установки. Единственным недостатком является то, что у вас нет особого контроля над тем, что используется из пакетов сайта; вы можете установить значение allowed-eggs-from-site-packages пустым, чтобы остановить использование яиц, но все пакеты будут доступны. В любом случае, вот фрагмент из моей сборки: 

[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
0