Настройка виртуального окружения Django virtualenv

Хорошим тоном считается ставить Django в виртуальное окружение. Также это может оказаться удобным, когда на сервере необходимо держать разные версии Django или python, или любого друго программного обеспечения.
Устанавливаем менеджер пакетов python

aptitude install python-pip python-dev build-essential
pip install --upgrade pip
pip install virtualenv

на Debian Squeeze может возникнуть такая ошибка

Traceback (most recent call last):
  File "/usr/bin/pip", line 11, in 
    from pip.vcs import vcs, get_src_requirement, import_vcs_support
ImportError: cannot import name import_vcs_support
Traceback (most recent call last):
  File "/usr/bin/pip", line 8, in <module>
    from pip.baseparser import parser
ImportError: cannot import name parser

Лечится следующим образом

easy_install pip
rm /usr/bin/pip
ln -sv /usr/local/bin/pip-2.6 /usr/bin/pip
pip install pip --upgrade

Затем еще раз пробуем установить virtualenv

pip install virtualenv

Для простоты работы с virtualenv будем использовать virtualenvwrapper. Ставим.

pip install virtualenvwrapper

Создаем папку, где будут лежать все окружения
Создаем папку, где будут лежать виртуальные окружения

mkdir ~/.virtualenvs

Добавляем в ~.bashrc

export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

django virtualenv debian
Перечитываем изменения

source .bashrc

virtualenv готов к работе, можно создавать виртуальное окружение.

  • Создать виртуальное окружение
    mkvirtualenv catalog

    django virtualenv debian howto

  • Активировать виртуальное окружение
    workon catalog

    django virtualenv howto

  • Деактивировать виртуальное окружение
    deactivate catalog
  • Удалить виртуальное окружение
    rmvirtualenv catalog

Установим Django в наше виртаульное окружение catalog

(catalog) pip install django

django virtualenv howto

Настройка виртуального окружения Django virtualenv: 13 комментариев

  1. Тяжело дается мне все это. Но благодоря вашей статье начал немного разбираться.

    1. Рад, что оказался полезен, пишите, если возникнут вопросы, постараюсь помочь.

  2. Ни в одном блин гайде в интернете нету описания пошагово как установить всё это на Windows.
    pip virtualenv django Flask
    Перелопатил кучу инфы, с горем пополам установил всё это, а толку? Везде вводят непонятные не юзеру юниксовых и линукс систем команды, и никто и нигде не объясняет их куда вводить, как поставить нужную консоль… бесит

        1. Джанга поставляется со встроенным веб сервером для разработки. Вся установка сводится к инсталляции в систему питона и менеджера пакетов pip. Дальше все как в остальных системах. По шагам все расписано в документации https://docs.djangoproject.com/en/1.7/howto/windows/

  3. Здравствуйте! Я честно перерыл уже два десятка статей за период с 2011 по середину 2014 года, но так и не разобрался окончательно, как подготовить боевой сервер для Django с такими вводными:
    — ОС CentOS 7
    — в системе стоит python = python2.7
    — нужно поставить python >= 3.4
    1. Сносить системный python нельзя, тогда остаётся только виртуальное окружение, так?
    2. Как я понял, virtualenv, virtualenvwrapper устарели? С python3.4 поставляется некий pyvenv, но какой функционал он покрывает и как им пользоваться я не понял.
    3. Пишут, что для uWSGI специально создаётся пользователь, от имени которого всё и запускается.
    Разъясните мне, пожалуйста, как быть хотя бы с вирт. окружением, как правильно его поставить и какими средствами?

    1. Здравствуйте, нет ничего страшного в том, чтобы держать несколько версий питона на одном хосте. Просто устаналивайте питон 3.4 вашим менеджером пакетов. Виртуальные окружения нужны для изоляции пакетов, например вы хотите держать несколько версий джанги на одном хосте. С 3-м питоном идет встроенная поддержка виртуальных окружений, поэтому необходимость в virtualenv отпадает.
      uWSGI я ставлю в каждое виртуальное окружение отдельно pip install uwsgi.
      Для запуска uWSGI от пользователя в uwsgi.ini необходимо указать uid и gid этого пользователя
      uid = some_user (пользователь)
      gid = some_user (группа)
      Подробнее можно здесь посмотреть

      1. Виталий, спасибо, что ответили! Извините, если вопросы глупые.
        Сейчас немного лучше понимаю, но остались пробелы, в основном архитектурного плана.
        Подскажите, пожалуйста, где я неправ и как что сконфигурировать.
        ВОПРОСЫ:
        1. Какую создать структуру каталогов для конфигов, сайтов и, возможно, виртуального окружения?
        2. Что использовать из вирт. окружения, а что из системы?
        Вопрос про структуру каталогов возник вот из чего:
        1) использовать ли вирт. окружение? если да, то одно для всех приложений или каждому свое?
        2) как быть с пользователями и правами доступа к каталогам? Должен быть как минимум пользователь nginx, и наверное отдельный для uwsgi?
        Приложения должны работать под python3.4.
        Установлены:
        — CentOS 7
        — python версии 2.7.5 шёл с системой,
        — python версии 3.4.3 установил из исходников, /usr/local/bin/python3.4
        — pyvenv-3.4 (идёт с питоном), /usr/local/bin/pyvenv-3.4
        — nginx версии 1.8.0, c оф. сайта, запускается автоматом при старте от пользователя nginx
        — uWSGI версии 2.0.11.1
        В вирт. окружении имеются:
        — Django версии 1.8.3,
        — uWSGI версии 2.0.11.1

        1. По порядку:
          1) Структуру каталогов можно создавать произвольную, как вам удобнее и понятнее. Я обычно делаю что-то вроде:
          /home/ufadormash.ru/djcode/project — здесь сам проект
          /home/ufadormash.ru/djcode/logs — здесь логи nginx, uwsgi, etc
          /home/ufadormash.ru/djcode/etc — здесь конфиги
          /home/ufadormash.ru/djcode/var — здесь pidы и, например, кеш сфинкса
          2) В виртуальное окружение можно ставить пакеты, относящиеся непосредственно к проекту (Django, батарейки и тд), на системном уровне — к серверу.
          3) Есть смысл создавать виртуальное окружение под каждый проект, тогда вы легко сможете держать целый зоопарк пакетов на одном сервере.
          4) С правами в целом все тривиально, nginx-у нужны доступы только к статике — это папки media и static, uWSGI должен запускаться от того же пользователя, кто владеет проектом посмотрите здесь пост достаточно старый, но смысл не изменился. Supervisor нужен для того, чтобы удобно было управлять процессами uWSGI

          1. Пытался установить supervisor, получил в ответ «…Supervisor requires Python 2.4 or later but does not work on any version of Python 3. You are using version 3.4.3. Please install using a supported version.»
            В супервизоре как-то настраивается версия питона для запуска uwsgi? Не понял, как он может запустить uwsgi на нужной версии питона, в конфиге вроде не указано явно.

          2. пишут, что можно использоваться форк для совместимости с 3-м питоном.

          3. (Виталий, Вам бы поправить стили для ссылок, они не отличаются от текста)

Добавить комментарий

Ваш адрес email не будет опубликован.