Pull to refresh

Comments 6

UFO just landed and posted this here
согласен. в принципе, тем хуже для примера. здесь я хотел показать, что virtualenv'у, устанавливаемому таким способом, можно передавать знакомые параметры.
В продолжении темы.
Если нужные зависимости прописать в файл requirements.pip, например:

django==1.2.4
-e hg+http://bitbucket.org/andrewgodwin/south/@stableish#egg=South-stable

и добавить в начало запускающего модуля вашего проекта вот такой код:

#!/usr/bin/env python
try:
    from ve_setup import use_virtualenv
except ImportError:
    import urllib
    urllib.retrive("http://tiny.cc/ve-setup", 've_setup.py')
    from ve_setup import use_virtualenv
use_virtualenv(['--distribute', "python"], requirements="requirements.pip", activate=True)

# application code
from django.core.management import execute_manager
...

тогда все необходимое установится автоматически при первом запуске скрипта, и сразу же станет доступным к использованию.
UFO just landed and posted this here
В принципе, я согласен. Но есть вырожденные ситуации, где, как мне кажется, это может быть полезно.

Например, если ваше приложение и есть инсталлятор — где инициализация virtualenv лишь первый шаг, а дальше накладываются пачти, создаются конфиги и т.п.

Я использую такую возможность в скрипте, запускающем тесты для проекта. Это создает единую точку входа, упрощая интеграцию с CI-сервером. А «интегрированный» деплоймент позволяет лишний раз убедиться, что все зависимости прописаны.

У pip есть замечательная фича — он умеет создавать бандлы (bundle) для установки всех зависимостей «оффлайн». Единственная проблема — для распаковки бандла на целевом хосте должен быть установлен сам pip, желательно не самый старый. Путем такого трюка с virtualenv это ограничение достаточно легко обходится.
Не помешало бы словами объяснить как это работает, и главное — чем это лучше добавления в PYTHONPATH папки, куда при необходимости можно закопировать нужные модули? :)
Sign up to leave a comment.

Articles