Как правильно настроить virtualenvwrapper?

Question

[evve]

Привет всем!
Недавно решил попробовать virtualenvwrapper. Нашел инструкцию https://virtualenvwrapper.readthedocs.org/en/lates...
Сомневаюсь, что я все правильно сделал и прошу подсказать мне.

Итак, ставлю:
sudo pip install --install-option="--user" virtualenvwrapper

Затем настраиваю баш:
export WORKON_HOME=$HOME/web/proj-env #путь до виртуального окружения проекта
export PROJECT_HOME=$HOME/web/proj #путь где будет код проекта
export VIRTUALENVWRAPPER_SCRIPT=/usr/local/bin/virtualenvwrapper.sh
source /usr/local/bin/virtualenvwrapper_lazy.sh

Далее перехожу в папку с кодом проекта ~/web/proj и по-моему мнению у меня уже должно быть запущено виртуальное окружение, но нет, каждый раз после закрытия терминала нужно делать mkvirtualenv proj-env. Без этого не работает python manage.py runserver - стандартная ошибка:

Traceback (most recent call last):
File "manage.py", line 8, in
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

Если это действительно так, то в чем принципиальное отличие от простого виртуального окружения, когда нужно делать source bin/activate ?

Кстати, при запуске терминала сообщение: "bash: /usr/share/virtualenvwrapper/virtualenvwrapper_lazy.sh: Нет такого файла или каталога"
Несколько раз удалял, ставил - все равно есть. В файле ~/.bashrc ничего кроме добавленных строк (описанных мною выше) нет...

Answer 1

[marazmiki]

Далее перехожу в папку с кодом проекта ~/web/proj и по-моему мнению у меня уже должно быть запущено виртуальное окружение

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

Как по мне, единственный плюс (хотя ещё как посмотреть, плюс ли это) виртуалэнввраппера — это то, что все виртуальные окружения хранятся в одной директории.

Я считаю гораздо более удобной модель, которую Вы по сути описали: когда виртуальное окружение лежит непосредственно в директории проекта, разумеется, под гитигнором. И при входе в директорию проекта окружение автоматически активируется. При выходе, соответственно, деактивируется. Тоже автоматически.

Пользуюсь этим подходом больше трёх лет, доволен как слон и искренне не понимаю тех, кто восторгается virtualenvwrapper'ом.

Comments

[bromzh]

Враппер имеет много хороших фишек. Например, просмотр всех окружений, переход к ним 1-й командой, хуки для действий. Ну и централизованно держать окружения имхо лучше, чем попроектно. Ведь бывают разные случаи: проекту надо 2 и более окружений (для тестирования, например, работоспособности во 2-й и 3-й версиях), или нужно виртуальное окружение, не привязанное к проекту (у меня так стоит ipython notebook).

[marazmiki]

bromzh: что ж, каждому своё. Но мой личный опыт (с которым, кстати, согласны все команды, с которыми довелось поработать) показывает, что:

• список всех доступных окружений не нужен никому вообще никогда;
  
• при работе над одним проектом имеет значение только лишь одно окружение — окружение проекта
  
• а для работоспособности проекта человечество изобрело tox и прочие средства CI. Нужно просто не лениться писать тесты.
  

Что же касается случаев, когда какой-то софт прям очень-очень-очень хочется поставить в окружение, то можно поставить его в окружение, а вызывать с неявной активацией. Благо .bashrc позволяет это делать

[bromzh]

marazmiki: Для проекта нет разницы, где располагается папка с окружением. Но централизация имеет несколько преимуществ. Ну и сам враппер добавляет несколько крайне удобных команд, возможных в том числе и из-за централизации:

• Выполнение команды во всех репозиториях. Удобно, если, например, нужно обновить pip/setuptools везде.
  
• Создать временное окружение (при деактивации удаляется)
  
• Копирование окружений
  
• Добавление внешних директорий к окружению
  
• Включать/выключать глобальные пакеты
  

Понятно, что и без враппера можно жить, но с ним многим удобнее из-за этих небольших, но приятных бонусов.

[marazmiki]

bromzh:

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

Разумеется. Это имеет значение для человека, который, увы, подвержен одноимённому фактору. Что стоит перепутать окружение и гадать, почему программа не запускается или работает не так, как положено. Или забыть, как называется окружение и долго и мучительно вспоминать его название. Или даже как называется команда workon :-)

Остальные перечисленные полезности у меня вызывают некоторые сомнения.

Выполнение команды во всех репозиториях. Удобно, если, например, нужно обновить pip/setuptools везде

А потом удивляться, почему в одном окружении всё ок, а в другом нет.

Создать временное окружение (при деактивации удаляется)

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

Добавление внешних директорий к окружению

Опять же, не могу представить кейс. Это теоретически может быть полезно при разработке распространяемых пакетов, но в этом случае лишено смысла, ибо setup.py develop.

Включать/выключать глобальные пакеты

Субъективное мнение: манипуляции с systemwide самый настоящий антипаттерн. В системе должен быть pip, pyvenv/virtualenv и, вроде бы, всё. Наследование окружения от global site packages в итоге неизбежно вызывает вагон неудовлетворённых зависимостей.

Копирование окружений

Звучит интересно, но не уверен в чистоте решения примерно по той же причине, что и прошлый пункт. Окружения должны быть изолированы друг от друга, никаких внешних зависимостей. Да и лишние пакеты ни к чему. Поэтому, по-моему, правильнее создавать окружения с нуля. Благо с wheels это делается крайне быстро.

[evve]

marazmiki: Да-да, я искал именно то, что вы описали. виртуальное окружение для каждого проекта свое и активируется при переходе в папку с проектом, деактивируется при выходе. А чем вы пользуетесь?

[marazmiki]

evve: я в своё время пытался написать велосипед на эту тему, но сейчас понимаю, что он не очень хорош. Главным образом потому что если создать новый терминал, он автоматически не активируется из-за отсутствия некоторых переменных окружения. А ещё в нём название директории виртуалэнва захардкожено (.env). Хотя это, возможно, и не так плохо.

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

Answer 2

[sim3x]

каждый раз после закрытия терминала нужно делать

workon proj-env

Расположение скрипта
locate virtualenvwrapper.sh

Answer 3

[bromzh]

echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

Теперь при запуске терминала всё будет работать.
И ничего не надо экспортировать отдельно, ты должен 1 раз установить сам враппер, а потом каждый раз делать source. Это особенности баша, по другому не сделать. Строчки выше добавляют в файл, который запускается при старте терминала с башем инициализацию враппера.