3 votes

Buildout : utiliser les dépendances du système Python

J'essaie d'utiliser buildout pour un paquet Python qui, lorsqu'il est utilisé, dépend de 2 modules d'extension : dbus-python y pygobjet . Les deux modules font échouer buildout : dbus-python ne dispose pas d'un setup.py tandis que pygobject en a un mais dont l'utilisation est déconseillée -- à la place configure, make, make install doit être utilisé. Ainsi, buildout n'est pas capable d'installer ces dépendances dans l'environnement de développement.

Voici mon buildout.cfg :

[buildout]
develop = .
parts = eggs

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

setup.py pour le foobar Le paquet contient :

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

En cherchant une solution, je suis tombée sur cette recette z3c.recipe.scripts et son la capacité d'utiliser les œufs installés à l'échelle du système . Cependant, lorsqu'il est appliqué à mon buildout.cfg ..

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

cela semble n'avoir aucun effet (l'échec persiste), bien que les deux paquets ( dbus , gobjet ) sont installés dans mon système Python. Il en va de même lorsque je supprime le allowed-eggs.. ligne.

Ma question : Est-ce que je me suis trompé sur le plan de la conception ou est-ce qu'il y a une erreur dans mon buildout.cfg ?

Je sais qu'il y a zc.recipe.cmmi une recette qui installe les œufs en utilisant configure, make, make install . Cependant, une simple référence aux œufs Python du système serait suffisante dans mon cas. Je n'ai pas besoin d'un environnement 100% reproductible généré par buildout. Aussi, dbus-python y pygobjet sont installées par défaut sur la plupart des systèmes de bureau Linux, l'environnement dans lequel foobar est destiné à être utilisé.

3voto

Reinout van Rees Points 5483

Je n'ai pas réussi à faire fonctionner les derniers buildouts 1.5.x avec les paquets système, également. Il y a un moyen : épingler les versions. De cette façon, zc.buildout 1.5.x le récupérera.

[buildout]
...
versions = versions

[versions]
pygobject = 1.2.3

Alternativement, ce que je fais, vous pouvez utiliser l'ancien buildout 1.4.4 (vous aurez besoin d'un bootstrap.py spécial pour cela, google le) en combinaison avec osc.recipe.sysegg .

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

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

Personnellement, j'opterais pour la solution osc.recipe.sysegg, car elle est fiable.

2voto

Ross Patterson Points 4331

Vous voudrez peut-être utiliser une partie CMMI pour chacune de ces distributions python au comportement médiocre et utiliser la fonction extra-paths pour votre python pour s'assurer que les parties CMMI sont incluses dans le chemin python.

2voto

Oben Sonne Points 6342

Grâce à la réponse et aux commentaires de @Rainout, j'ai trouvé la source réelle de mon problème. Le problème n'est pas dans buildout ou ma configuration mais dans les bindings Python pour DBus et Gobject : ces paquets ne sont pas distribués comme des œufs mais comme des paquets simples.

Ainsi, bien que ces paquets puissent être récupérés via PyPI, ils ne peuvent pas être utilisés dans une infrastructure qui s'attend à ce que les paquets Python soient livrés en tant que œufs . En pratique, cela signifie que les dépendances de ces paquets ne doivent pas être listées dans setup.py mais doivent être traitées d'une autre manière (voire pas du tout).

0voto

Daniel Points 507

La meilleure façon de procéder que j'ai trouvée est de mettre include-site-packages à true, puis d'utiliser la fonction recette de mockedeggs pour faire croire à setuptools que les oeufs sont disponibles pendant l'installation. Le seul inconvénient est que vous n'avez pas beaucoup de contrôle sur ce qui est utilisé à partir des paquets du site ; vous pouvez définir allowed-eggs-from-site-packages à vide pour empêcher l'utilisation des œufs, mais tous les paquets seront disponibles. Bref, voici un extrait de mon 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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X