Вопрос

Я возился с комбинацией buildout и virtualenv, чтобы настроить изолированный среда разработки на Python, позволяющая создавать воспроизводимые сборки.

Существует рецепт сборки, который позволяет интегрировать virtualenv в сборку:

 tl.buildout_virtual_python

При этом мой buildout.cfg выглядит так:

[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

Это приведет к развертыванию двух исполняемых файлов в ./bin/:

vp
script

Когда я запускаю vp, я, как и ожидалось, получаю интерактивное изолированное диалоговое окно Python (не могу загрузить пакеты из системы).Чего я ожидаю сейчас, так это того, что если я побегу

./bin/script 

что используется изолированный интерпретатор Python.Но это не так, он не изолирован, как «vp» (это означает, что я могу импортировать библиотеки с системного уровня).Однако я могу запустить:

./bin/vp ./bin/script

Который запустит скрипт в изолированной среде, как я и хотел.Но должен быть способ указать это без объединения команд, иначе buildout решит только половину проблем, на которые я надеялся :)

Спасибо за вашу помощь!Патрик

Это было полезно?

Решение

Вам не нужен virtualenv:buildout уже предоставляет изолированную среду, как и virtualenv.

В качестве примера рассмотрим файлы, создаваемые buildout в каталоге bin.У них будет что-то вроде:

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

Итак sys.path полностью заменяется тем, что buildout хочет иметь на пути:тот же метод изоляции, что и virtualenv.

Другие советы

zc.buildout 2.0 и позже больше не обеспечивает изолированную среду.

Но виртуальная среда 1.9 и более поздних версий обеспечивает полную изоляцию (в том числе отсутствие установки инструментов настройки).

Таким образом, самый простой способ получить сборку в полностью контролируемой среде — это выполнить следующие шаги (здесь, т.е.для Python 2.7):

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

Предварительные условия:

  • bootstrap.py должен быть последним, соответствующим версии сборки, которую вы используете.Вы найдете последние новости на http://downloads.buildout.org/2/

  • Если в вашей сборке есть какие-либо контакты версий, убедитесь, что они не закрепляют саму сборку или рецепты/расширения к версиям, несовместимым с zc.buildout 2 или более поздней версии.

У меня возникла проблема с запуском сборки с использованием начальной загрузки на сервере Ubuntu, с тех пор я использую virtualenv и сборку вместе.Просто создайте virualenv и установите в него сборку.Таким образом, в систему необходимо установить только virtualenv (теоретически1).

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

Также сообщите buildout, чтобы он поместил свои скрипты в каталог virtual/bin/, чтобы скрипты появлялись там. $PATH.

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

1:На практике вам, вероятно, понадобится перенести то, что требует компиляции, на системный уровень, требующий компиляции.Яйца, такие как MySQL или Memcache.

Я никогда раньше не пользовалась этим рецептом, но первое, что я бы попробовала, это:

[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

Если это не сработает, вы обычно можете открыть сценарии (в данном случае vp и script) в текстовом редакторе и просмотреть пути Python, которые они используют.Если вы используете Windows, обычно там будет файл с именем <script_name>-script.py.В данном случае это будут vp-script.py и script-script.py.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top