web-dev-qa-db-ja.com

virtualenv / virtualenvwrapperのシェル環境のセットアップ

質問は、 virtualenvwrapper のシェルセットアップ、 virtualenv （ python guide ）の拡張についてです。

同様の質問が何度も聞かれましたが、答えは異なります。

いくつかの可能なオプションを考慮して、環境セットアップと関数定義スクリプトをトリガーする「最良の」方法はどれですか。

  1. 〜/ .profile
  2. 〜./。bash_profile、〜/ .zprofile
  3. 〜。/ bash_login、〜。/ zlogin（難解なオプション）
  4. 〜/ .bashrc、〜/ .zshrc

virtualenvwrapperガイド 状態：

"シェル起動ファイル（.bashrc、.profileなど）に3行を追加して、仮想環境が存在する場所を設定します"

利用可能なオプションを検討する前に、可能な「ユースケース」を検討することが重要です。

  • ターミナル（コンソール）ログイン（Xなし、ローカル）
  • sshリモートログイン（インタラクティブ）
  • sshリモートコマンド実行（非対話型）
  • 「グラフィカル」ログイン（GDM）の後、ターミナル（gnome-terminal）を開きます
  • 「デスクトップ」ファイルExec呼び出しを介して、DE（Gnome）で直接
  • xclientから間接的に呼び出されます（例：emacsサブプロセス）
  • ユーザーのcronジョブとして記載されています
  • root以外のユーザーのsystemdサービス（またはソケット）として登録されています
  • サービスサブプロセス（httpd CGIなど）によって間接的に開始されます

Xグラフィカルログインをサポートするために、パスを設定する唯一の方法は、〜/ .profileを介して、ソースを/ etc/gdm/Xsession、後/ etc/profile

これはパスと環境の設定に最適な場所ですが、virtualenvwrapper関数を正しく定義できません（ "workon"）

その理由は、XsessionがPOSIX/ bin/shシェルで実行され、virtualenvwrapperでサポートされていないためです （bash、zsh、ksh support ）

一部のディストリビューションはdashをPOSIXシェルとして採用しましたが、他のディストリビューションは依然としてPOSIXモードのbash呼び出しに依存しています。

見る

非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は仮想環境ではなく「システム」環境で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の呼び出しに対して同様のことができるでしょう。

見る：

この構成はすべて見苦しく、保守が困難です。より良い解決策は可能ですか？

bashzshsystemdgdmvirtualenv
2
hute37

しかし、結局のところ、virtualenvがグローバルでアクティブである必要があるのはなぜですかgnome-Shellコンテキスト？

これは確かにすべてを壊しますシステムレベル pythonインストールされたアプリケーション。

したがって、only virtualenvアプリケーションを開始する安全な方法は、ターミナルシェルから開始することです。

おそらく、〜/ .bash_profile〜/ .zprofileでactivate環境を有効にして、login -シェルターミナルのオプション。

〜/ .bashrcを使用する代替設定は、サブシェルで問題を引き起こす可能性があるため、避ける必要があります。

そう、

  • ログインオプションを有効にする
  • ターミナルを起動します（またはbash/zsh --login in xterm ...）
  • "workon"
  • 次に、ターミナルシェルからemacs（サーバー）を起動します。

gnome-Shellからvirtualenvアプリケーションを実行するには、デスクトップファイルは、実行前にenv activateをソースとする専用のラッパースクリプトを実行する必要があります。

一般的なwrapperの場合（Ruby 'bundle exec'およびrvmのものと同様）、見る：

たぶん「再ハッシュ」が必要です...

1
hute37