virtualenv: виртуальные окружения

Много у вас разных питонячих проектов работают на одном сервере? У меня вот да. Все ли они использую одни и те же библиотеки или версии библиотек? Нет. Так как сделать, чтобы можно было удобно поддерживать всё это многообразие?

Давным дано я предлагал один вариант - использовать svn:externals и таскать зависимости (код сторонних библиотек и приложений) с собой. Но такой способ очень ограничен в своем применении. Вы должны использовать VCS (subversion или иные поддерживающие аналогичные концепции) для развертывания проекта на сервере и все зависимости тоже должны быть доступны в той же системе контроля версий. Но так случается очень редко. Да и потом далеко не всегда VCS вообще используются для выкладки проектов. Пакетные системы во многих случаях удобней.

Создание изолированных окружений задача довольно давнишняя. И в питонячем мире решается разными способами уже давно. Одним из инструментов является - virtualenv.

Создать окружение просто:

virtualenv myenv

После выполнения этой команды создается директория myenv в который находится некое подмножество unix-like корневой файловой системы. В директории myenv/bin будет лежать бинарник питона, и несколько дополнительных скриптов. В myenv/lib - дерево каталогов, повторяющее оное у текущего установленного питона в системе.

Для того чтобы питонячий код работал в этом окружении, его надо запускать, используя myenv/bin/python, или подключив к своему скрипту вспомогательный модуль myenv/bin/activate.

Так же в myenv/bin будет специальный easy_install скрипт, через который можно устанавливать в это окружение дополнительные пакеты.

На самом деле это окружение не совсем изолированное. Если какой-то пакет не установлен в нем самом, то будет использован тот который установлен глобально в системе (если там он всё-таки есть). В большинстве случаев это удобно. Имеет смысл железобетонные пакеты, которые не часто обновляются, иметь не в каждом окружении отдельно, а глобально в системе, чтобы все могли им пользоваться.

Но это окно в глобальный мир можно закрыть - достаточно при создании окружения указать опцию --no-site-packages. В таком случае доступ из окружение к глобально установленным пакетам будет закрыт.

Я стал применять virtualenv относительно недавно. В момент когда решил занять кардинальной перестройкой блога. На прошлом своем опыте я понял, что иметь независимые инстансы проекта на одном сервере это насущная необходимость для удобной разработки, тестирования и выкладки в мир.

Причем при таком подходе я смог добиться повторяемости установок - я могу установить неограниченное число инстансов проекта на один сервер с нуля. И все они будут независимы друг от друга и изменения в одном никак не затрагивают другие.

Построив систему на базе независимых окружений совместно с pip и fabric, поддерживать и развивать весь зоопарк проектов стало значительно легче. Рекомендую.

Комментарии 11

  1. lorien написал:

    Правильно ли я понял идею, что нужно создать myenv директорию, установить туда специфические либы и внести это в репозиторий проекта. Или подразумевается, что myenv не принадлежит репозиторию и как-то по другому на сервер доставляется?

    Оставлен 27 Апрель 2009 в 02:06
  2. DyadyaZed написал:

    Спасибо, очень интересная тема. Раскройте ее по возможности глубже. Был бы благодарен за примеры скриптов с использованием pip, fabric.

    Оставлен 27 Апрель 2009 в 13:50
  3. Александр Кошелев написал:

    Или подразумевается, что myenv не принадлежит репозиторию и как-то по другому на сервер доставляется?

    Да. Окружение должно создаваться некой "системой выкладки" уже целевой машине. Потом, в него ставится сам проект и все необходимые зависимости. Получается изолированный sandbox, в котором живет проект на сервере.

    Хранить в репозитории окружение конечно же нет необходимости.

    Оставлен 27 Апрель 2009 в 17:56
  4. Александр Кошелев написал:

    Спасибо, очень интересная тема. Раскройте ее по возможности глубже. Был бы благодарен за примеры скриптов с использованием pip, fabric.

    Постараюсь:-)

    Оставлен 27 Апрель 2009 в 17:56
  5. Sergey Kishchenko написал:

    Buildout не пробовал?

    Оставлен 28 Апрель 2009 в 00:28
  6. Александр Кошелев написал:

    Buildout не пробовал?

    Присматриваюсь с опаской к нему. И по мере разглядывания опаска растет:-)

    Мне кажется ,что это не true-django инструмент.

    Оставлен 28 Апрель 2009 в 01:27
  7. Sergey Kishchenko написал:

    Он тру zope инструмент, но зато делает всё сам :)

    Оставлен 28 Апрель 2009 в 01:32
  8. Александр Кошелев написал:

    Так я про тоже - он из другой вселенной.:-)

    Надо, конечно его пощупать детально, но пока нет даже особого желания и задачи подходящей.

    Укрощение узкоспециализированной упомянутой в посте троицы доставляет море фана.

    Оставлен 28 Апрель 2009 в 01:45
  9. igorekk написал:

    Про Buildout и VirtualEnv можно почитать тут: http://book.pdfchm.com/python-for-unix-and-linux-system-administration-13037/

    Оставлен 28 Апрель 2009 в 10:48
  10. http://blog.uptimebox.ru/ написал:

    Недавно писал мануал с конкретными примерами для pip+virtualenv: http://blog.uptimebox.ru/2009/03/python.html

    Оставлен 05 Май 2009 в 21:56
  11. Cykooz написал:

    Я тоже начинал с использывания virtualenv, но когда разобрался с buildout, то понял насколько это проще и для разработки и для развёртывания. Одним из преимуществ buildout для меня было то, что у меня пропали все проблемы при использывать mod_wsgi. Там есть параметр WSGI_Python_Home, который для виртуальных сред будет разный и потому возникают проблемы с запуском нескольких проектов на одном Апаче. Тоже относится и к настройке проекта в Eclipse (не надо для каждого проекта указывать отдельный python). Кстати мнение, что buildout это инстумент заточеный под zope, по мне дак очень преувеличено. И то что это не true-django - то я бы сказал в таком случае, что это скорее django еще не совсем догняет современых тенденций в разработке на python. Сейчас многие пакеты питона оформляются в виде eggs, а большие проекты разделяют на независимые (по возможности) пакеты. Даже сам Jacob Kaplan-Moss обратил внимание на buildout и видимо ему он понравился - http://jacobian.org/writing/django-apps-with-buildout/. С его слов buidout - это очень удобная штука для разработки приложений.

    Сейчас все свои пректы (django, wsgi-middleware, zope и др.) делаю с использыванием buildout - это решает много проблем как с разработкой так и с развёртыванием приложения.

    Оставлен 19 Июнь 2009 в 13:24

Пингбеки 1

  1. От Python, Django и virtualenv « [alder@freedom] 02 Апрель 2011 в 14:22

    ружения для Python-проектов, то самое время начать это делать. Профит от этого весьма очевиден — каждое Python-приложение использует только нужные ему библиотеки (нужных версий) и требуемую версию Python. А еще это снижает риск возникновения конфликтов