virtualenv в помощь

В этой статье хочу поделиться опытом того, как можно без лишней головной боли организовать тестирование web-приложения , написанного на python c различными версиями этого языка. И даже с различными версиями того или иного фреймворка (django, pylons etc)...если, конечно , фреймворк используется.
Итак , есть сервер , для определенности : на нем установлен linux.. для еще большей определенности - debian )
Любой linux - дистрибутив уже включает в себя ту или иную версию python. Допустим "из коробки" имеем python v2.5. Мы же хотим протестировать наше гипотетическое приложение на совместимость с python 2.5, 2.6 и 2.7 (на совместимость с версией 3 лучше не тестировать - под нее надо писать отдельно =), чтобы быть уверенным, что наше приложение будет работать на большинстве python-хостингов.

1. доставляем отсутствующие версии python. Для этого wget-ом, например, выкачиваем соответствующие исходники, распаковываем (tar), конфигурируем НЕ ЗАБЫВАЯ УКАЗЫВАТЬ ПРЕФИКС установки отдельно для каждой версии python, затем make и make install. В итоге получаем:
   • /usr/bin/python - дефолтный
   • /usr/python2.6/bin/python
   • /usr/python2.7/bin/python
2. теперь самое интересное - у нас три одинаковых бинаря python в трех разных местах. Если вызвать python из командной строки, то будет дернут тот, чей путь левее всего в PATH. Как быть? каждый раз руками менять PATH? мучаться с симлинками? Слава Богу нет. Нам на помощь приходит замечательная штукенция - virtualenv !

   
   sudo apt-get install virtualenv
   mkdir ~/projects/
   cd projects
   virtualenv --no-site-packages -p /usr/bin/python app_test_python2.5
   virtualenv --no-site-packages -p /usr/python2.6/bin/python app_test_python2.6
   virtualenv --no-site-packages -p /usr/python2.7/bin/python app_test_python2.7
   

   В результате мы имеем три директории - по одной для каждой версии питона. Интересное внутри этих директорий. Внутри же создается окружение - бинари, инсталляторы библиотек (pip , easy_install) - сюда же надо помещать и код тестируемого приложения, отсюда же и деплоить с локальным web-сервером (apache, nginx..)
3. еще не все. Чтобы работать в окружении , надо его активировать:

   
   cd ~projects/app_test_python2.6
   . env/bin/activate
   
   

   теперь можно не боясь вызвать python, pip, easy_install - будет вызвана именно версия 2.6, будут использованы именно библиотеки для версии 2.6 и ставиться будут они не в /usr/lib/python , а в ~projects/app_test_python2.6/lib !
   

Полная изоляция, никакой мороки и путаницы.
Таким образом, создавая для каждой тестовой конфигурации свое виртуальное окружение, мы не засираем систему хаотичными симлинками, конфликтующими версиями библиотек и т.д. и т.п. В общем сплошные плюсы.
Расписал, конечно, не все максимально детально. Но, думаю, тому , кто решить освоить эту технику организации тестовых стендов помогут гугл, здравый смысл и прямые руки )
p.s. только python к сожалению ( Пока писал стало интересно есть ли аналоги для perl, php ... )