Buildout et Virtualenv

Question

Je suis déconner avec la combinaison de buildout et virtualenv pour installer un isolé environnement de développement en python qui permet de faire des builds reproductibles.

Il y a une recette pour buildout qui vous permet d'intégrer virtualenv dans buildout:

tl.buildout_virtual_python 

Avec ce mon buildout.cfg ressemble à ceci:

[buildout] 
develop = . 
parts = script 
     virtualpython 


[virtualpython] 
recipe = tl.buildout_virtual_python 
headers = true 
executable-name = vp 
site-packages = false 

[script] 
recipe = zc.recipe.egg:scripts 
eggs = foo 
python = virtualpython 

Ce déploiera deux executables dans ./ bin /:

vp 
script 

Lorsque j'exécute vp, j'obtiens un dialogue python interactif et isolé, comme e xpected (ne peut charger aucun paquet du système). Ce que je me attends maintenant, est que si je lance

./bin/script 

que l'interpréteur python isolé est utilisé. Mais ce n'est pas le cas, ce n'est pas isolé car "vp" est (ce qui signifie que je peux importer des bibliothèques du niveau du système). Cependant je peux courir:

./bin/vp ./bin/script 

Qui exécutera le manuscrit dans un environnement isolé comme je le souhaitais. Mais il doit y avoir un moyen de spécifier ceci sans les commandes de chaînage sinon le buildout ne résout que la moitié des problèmes que j'espérais :)

Merci pour votre aide! Patrick

Answer 1

Vous n'avez pas besoin de virtualenv: le buildout fournit déjà un environnement isolé, tout comme virtualenv. Par exemple, regardez les fichiers buildout générés dans le répertoire bin. Ils ont quelque chose comme:

import sys 
sys.path[0:0] = [ 
    '/some/thing1.egg', 
    # and other things 
    ] 

Ainsi, le sys.path complètement remplacé par obtient ce que buildout veut avoir sur le chemin: la même méthode d'isolement que virtualenv.

Answer 2

Je ne l'ai jamais utilisé cette recette avant, mais la première chose que je voudrais essayer est ceci:

[buildout] 
develop = . 
parts = script 
     virtualpython 


[virtualpython] 
recipe = tl.buildout_virtual_python 
headers = true 
executable-name = vp 
site-packages = false 

[script] 
recipe = zc.recipe.egg:scripts 
eggs = foo 
python = virtualpython 
interpreter = vp 

Si cela ne fonctionne pas, vous pouvez généralement ouvrir les scripts (dans ce cas vp et script) dans un éditeur de texte et voir les chemins Python qu'ils utilisent. Si vous êtes sur Windows, il y aura généralement un fichier appelé <script_name>-script.py. Dans ce cas, ce serait vp-script.py et script-script.py.

Answer 3

J'avais un problème lors de l'exécution de buildout en utilisant bootstrap sur le serveur ubuntu, à partir de là j'utilise virtualenv et buildout ensemble. Créez simplement virualenv et installez le buildout dedans. De cette façon, seul virtualenv doit être installé dans le système (en théorie).

$ virtualenv [options_you_might_need] virtual 
$ source virtual/bin/activate 
$ pip install zc.buildout 
$ buildout -c <buildout.cfg> 

Dites aussi à buildout de mettre ses scripts dans le répertoire virtuel/bin /, que les scripts de façon apparaissent sur $PATH.

[buildout] 
bin-directory = ${buildout:directory}/virtual/bin 
... 

---

1: Dans la pratique, vous aurez probablement besoin d'œufs qu'exigez compilation au niveau du système qui nécessitent la compilation. Des oeufs comme mysql ou memcache.

Answer 4

zc.buildout 2.0 et plus tard ne fournit plus l'environnement isolé.

Mais virtualenv 1.9 et plus tard fournit une isolation complète (y compris pour ne pas installer setuptools).

Ainsi, la meilleure façon d'obtenir un buildout dans un environnement contrôlé complet est d'exécuter les étapes suivantes (ici par exemple pour Python 2.7 largement utilisé):

cd /path/to/buildout 
rm ./bin/python 
/path/to/virtualenv-2.7 --no-setuptools --no-site-packages --clear . 
./bin/python2.7 bootstrap.py 
./bin/buildout 

Préalables:

• bootstrap.py doit être récent et correspondre à la version de buildput que vous utilisez. S'il existe des broches de version dans votre buildout, assurez-vous qu'elles ne broient pas le buildout lui-même ou les recettes/extensions vers des versions non compatibles avec zc.buildout 2 ou ultérieur.