2

Вопрос в настройке оболочки для virtualenvwrapper, расширения для virtualenv (руководство по питону).

Подобные вопросы задавались много раз, но с большим количеством разных ответов:

Какой "лучший" способ запустить сценарий настройки среды и определения функции, учитывая несколько возможных вариантов:

  1. ~/.Profile
  2. ~./.bash_profile, ~/.zprofile
  3. ~./bash_login, ~./zlogin (эзотерическая опция)
  4. ~/.bashrc, ~/.zshrc

Руководство virtualenvwrapper гласит:

«Добавьте три строки в файл запуска оболочки (.bashrc, .profile и т.д.), Чтобы указать расположение, в котором должны жить виртуальные среды».

Прежде чем рассматривать доступные варианты, важно рассмотреть возможные варианты использования:

  • логин терминала (консоли) (без X, локально)
  • SSH удаленный вход (интерактивный)
  • выполнение удаленной команды ssh (не интерактивно)
  • после "графического" входа в систему (GDM), открытие терминала (gnome-терминал)
  • непосредственно в DE (Gnome), через "рабочий стол" из файла Exec
  • косвенно вызывается из xclient (например, подпроцесс emacs)
  • указано как задание для пользователя
  • зарегистрирован как сервис systemd (или сокет) для пользователя без полномочий root
  • косвенно запускается подпроцессом службы (например, httpd CGI)

Для поддержки графического входа в систему X единственный путь установить путь - через ~/.profile, который получает исходники через /etc/gdm/Xsession, после /etc/profile

Хотя это лучшее место для настройки пути и среды, оно не может правильно определить функции virtualenvwrapper ("workon")

Причина в том, что Xsession выполняется в оболочке POSIX /bin/sh , которая не поддерживается virtualenvwrapper (поддержка bash, zsh, ksh)

Некоторые дистрибутивы используют dash в качестве оболочки POSIX, в то время как другие все еще полагаются на вызов bash в режиме POSIX.

Увидеть

для исключения не bash/zsh/ksh.


В X логинах использование ~/.profile для (ручных) настроек среды работает:

export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME

определение функции virtualenvwrapper не работает;

source `which virtualenvwrapper.sh`

Альтернативой может быть поместить все в ~/bashrc

export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
source `which virtualenvwrapper.sh`

workon $ENV_NAME

Но это также не работает:

  1. X (gnome-shell) не инициализируется, поэтому команда .desktop files exec использует "системную" среду, а не виртуальную.
  2. среда, установленная каким-либо процессом (emacs), уничтожается переопределением ~/.bashrc

Пример:


Лучшим вариантом может быть смешанный раствор (не такой крутой ...)

В ~/.profile, ручная настройка среды

export WORKON_HOME=~/.virtualenvs
export ENV_NAME='myvirtualenv'
export VIRTUAL_ENV="$WORKON_HOME/$ENV_NAME"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME

В ~/.bash_profile или ~/.zprofile включите профиль POSIX и определение функции:

[ -f ~/.profile ] && source ~/.profile
[ -f `which virtualenvwrapper.sh` ] && source `which virtualenvwrapper.sh`

В gnome-terminal, включив опцию «login-shell» , определяются функции "workon" .

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

ssh localhost bash --login -c env

Может быть, что-то подобное можно сделать для вызова systemd и cron .

Увидеть:


Все эти настройки выглядят ужасно и сложно поддерживать. Возможно ли лучшее решение?

1 ответ1

1

Но, в конце концов, почему virtualenv должен быть активным в глобальном контексте оболочки gnome ?

Это наверняка сломает все установленные приложения Python системного уровня .

Таким образом, единственный безопасный способ запустить приложение virtualenv - это запуск из терминальной оболочки.

Возможно, безопаснее активировать среду в ~/.bash_profile ~/.zprofile, включив опцию login-shell в терминале.

Следует избегать альтернативной настройки, использующей ~/.bashrc, поскольку это может вызвать проблемы в подоболочках.

Так,

  • включить опцию входа в систему
  • запустить терминал (или bash/zsh --login в xterm ...)
  • "работа над"
  • затем запустите emacs (сервер) из оболочки терминала.

Чтобы запустить приложение virtualenv из gnome-shell, в файле рабочего стола должен быть выполнен специальный скрипт-обертка, который активирует источник env перед выполнением.

Обобщенную оболочку (похожую на ruby 'bundle exec' и rvm) смотрите:

Может быть, требуется повторное хеширование ...

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .