virtualenvwrapper 3.5

virtualenvwrapper は Ian Bicking の virtualenv ツールの拡張機能です。この拡張機能は仮想環境の作成・削除を行ったり、開発ワークフローを管理するラッパーを提供します。このラッパーを使うことで、開発環境の依存関係による競合を起こさず、同時に複数のプロジェクトで作業しやすくなります。

機能

  1. 1つの場所に全ての仮想環境を構成する
  2. 仮想環境を管理(作成、削除、コピー)するラッパー
  3. 1つのコマンドで仮想環境を切り替える
  4. コマンドの引数から仮想環境をタブ補完できる
  5. 全ての操作をユーザ設定でフックできる(ユーザカスタマイズ を参照)
  6. 共有できる拡張機能を作成できるプラグインシステム(virtualenvwrapper を拡張する を参照)

入門

virtualenvwrapper が提供する機能を説明するには、実際に使ってみるのが最も良い方法です。

まず初期化の作業があります。この作業の大半は一度だけ行う必要があります。pip でインストールした場所に依存する virtualenvwrapper.sh のパスを変更したり、 source /usr/local/bin/virtualenvwrapper.sh のコマンドをシェル起動時に読み込まれるファイルへ追加したりするでしょう。

$ pip install virtualenvwrapper
...
$ export WORKON_HOME=~/Envs
$ mkdir -p $WORKON_HOME
$ source /usr/local/bin/virtualenvwrapper.sh
$ mkvirtualenv env1
Installing
distribute..........................................
....................................................
....................................................
...............................done.
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/predeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/preactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postactivate  New python executable in env1/bin/python
(env1)$ ls $WORKON_HOME
env1 hook.log

これで作成した仮想環境へソフトウェアをインストールできます。

(env1)$ pip install django
Downloading/unpacking django
  Downloading Django-1.1.1.tar.gz (5.6Mb): 5.6Mb downloaded
  Running setup.py egg_info for package django
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.6/django-admin.py from 644 to 755
    changing mode of /Users/dhellmann/Envs/env1/bin/django-admin.py to 755
Successfully installed django

lssitepackages で新たにインストールしたパッケージを調べられます。

(env1)$ lssitepackages
Django-1.1.1-py2.6.egg-info     easy-install.pth
distribute-0.6.10-py2.6.egg     pip-0.6.3-py2.6.egg
django                          setuptools.pth

当然、1つだけの仮想環境に制限されるわけではりません。

(env1)$ ls $WORKON_HOME
env1            hook.log
(env1)$ mkvirtualenv env2
Installing distribute...............................
....................................................
....................................................
........... ...............................done.
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/predeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/preactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env2/bin/postactivate  New python executable in env2/bin/python
(env2)$ ls $WORKON_HOME
env1            env2            hook.log

workon で仮想環境を切り替えます。

(env2)$ workon env1
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Envs/env1
(env1)$

さらに workon コマンドは仮想環境名をタブ補完できます。そして、ある仮想環境がアクティブ化または非アクティブ化されるようにカスタムスクリプトを実行します(ユーザカスタマイズ を参照)。

(env1)$ echo 'cd $VIRTUAL_ENV' >> $WORKON_HOME/postactivate
(env1)$ workon env2
(env2)$ pwd
/Users/dhellmann/Envs/env2

新たな環境が作成されるときに postmkvirtualenv が実行されて、一般的に使用するツールを自動的にインストールします。

(env2)$ echo 'pip install sphinx' >> $WORKON_HOME/postmkvirtualenv
(env3)$ mkvirtualenv env3
New python executable in env3/bin/python
Installing distribute...............................
....................................................
....................................................
........... ...............................done.
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/predeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/preactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env3/bin/postactivate
Downloading/unpacking sphinx
  Downloading Sphinx-0.6.5.tar.gz (972Kb): 972Kb downloaded
  Running setup.py egg_info for package sphinx
    no previously-included directories found matching 'doc/_build'
Downloading/unpacking Pygments>=0.8 (from sphinx)
  Downloading Pygments-1.3.1.tar.gz (1.1Mb): 1.1Mb downloaded
  Running setup.py egg_info for package Pygments
Downloading/unpacking Jinja2>=2.1 (from sphinx)
  Downloading Jinja2-2.4.tar.gz (688Kb): 688Kb downloaded
  Running setup.py egg_info for package Jinja2
    warning: no previously-included files matching '*' found under directory 'docs/_build/doctrees'
Downloading/unpacking docutils>=0.4 (from sphinx)
  Downloading docutils-0.6.tar.gz (1.4Mb): 1.4Mb downloaded
  Running setup.py egg_info for package docutils
Installing collected packages: docutils, Jinja2, Pygments, sphinx
  Running setup.py install for docutils
  Running setup.py install for Jinja2
  Running setup.py install for Pygments
  Running setup.py install for sphinx
    no previously-included directories found matching 'doc/_build'
    Installing sphinx-build script to /Users/dhellmann/Envs/env3/bin
    Installing sphinx-quickstart script to /Users/dhellmann/Envs/env3/bin
    Installing sphinx-autogen script to /Users/dhellmann/Envs/env3/bin
Successfully installed docutils Jinja2 Pygments sphinx  (env3)$
(venv3)$ which sphinx-build
/Users/dhellmann/Envs/env3/bin/sphinx-build

コアパッケージで定義された既存機能(コマンドリファレンス を参照)、サードパーティのプラグイン(virtualenvwrapper を拡張する を参照)やユーザ定義スクリプト(ユーザカスタマイズ を参照)を組み合わせて、virtualenvwrapper は雑多な繰り返し行う操作を自動化する機会を提供します。

詳細内容

インストール

サポートシェル

virtualenvwrapper は Bourne シェル互換の構文をもつ一連のシェル 関数 です。Mac OS X と Linux 環境の、次のシェルで自動テストを行っています。

  • bash
  • ksh
  • zsh

その他のシェルでも動作するかもしれません。ここに記載されていないシェルで動作するのを発見したら私に教えてください。また、その他のシェルでも動作するように virtualenvwrapper を全く違うものに書き換えずに修正できるなら、 bitbucket のプロジェクトページ から pull リクエストを送ってください。あなたが非互換なシェル上で動作させるクローンを作成するなら、このページでリンクを張るので私に連絡してください。

MSYS

Python を Windows ネイティブにインストールした MSYS 環境でも virtualenvwrapper が使えます。そのためには、インストールした MSYS 環境へのルートパスを MSYS_HOME という環境変数で定義する必要があります。

export WORKON_HOME=$HOME/.virtualenvs
export MSYS_HOME=/c/msys/1.0
source /usr/local/bin/virtualenvwrapper.sh

または:

export WORKON_HOME=$HOME/.virtualenvs
export MSYS_HOME=C:\msys\1.0
source /usr/local/bin/virtualenvwrapper.sh

MSYS の設定によります。 MSYS_HOME/bin フォルダーに MSYS mktemp binary をインストールする必要があるかもしれません。

PowerShell

Guillermo López-Anglada は、Microsoft の PowerShell 環境で実行できるように virtualenvwrapper を移植しました。それは他の拡張機能と互換性がなく、(機能拡張というよりは) 大幅な再実装であることから、別に配布するようにしました。 virtualenvwrapper-powershell は、PyPI からダウンロードできます。

Python バージョン

virtualenvwrapper は Python 2.4 - 2.7 でテストされています。

基本的なインストール

virtualenvwrapper は、virtualenv がインストールされているグローバルな site-packages ディレクトリと同じところにインストールする必要があります。それを行うには、管理者特権が必要になるかもしれません。最も簡単なインストール方法は pip を使うことです。

$ pip install virtualenvwrapper

または:

$ sudo pip install virtualenvwrapper

Warning

virtualenv を使うと、たくさんの独立した Python 環境を作成できます。システム環境に依存する全ての Python 環境から同じパッケージを共有できるように、システムにインストールされている Python (virtualenv がアクティブではない) に virtualenv と virtualenvwrapper の2つだけはインストールする必要があります。

グローバルの site-packages ディレクトリにインストールする代わりに ユーザーのローカルディレクトリ (普通は ~/.local) にインストールできます。

$ pip install --install-option="--user" virtualenvwrapper

シェルの起動ファイル

シェルの起動ファイル (.bashrc, .profile など) に、仮想環境を構築する場所、開発中のプロジェクトディレクトリの場所、virtualenvwrapper がインストールしたシェルスクリプトの場所の3行を追加してください。

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

編集後に起動ファイルを再読み込みしてください (例えば source ~/.bashrc を実行する) 。

クイックスタート

  1. workon を実行する
  2. 仮想環境のリストが表示されるか、何も表示されない
  3. mkvirtualenv temp を実行する
  4. 新たな仮想環境 temp が作成されてアクティブ化される
  5. workon を実行する
  6. このときに temp の仮想環境が提供される

設定

virtualenvwrapper は、環境変数を変更することでカスタマイズできます。 virtualenvwrapper.sh が読み込まれる 前の シェルの起動ファイルで環境変数を設定してください。

仮想環境の場所

環境変数 WORKON_HOME は、virtualenvwrapper が使う仮想環境の場所を指定します。デフォルト設定は $HOME/.virtualenvs です。virtualenvwrapper が読み込まれたときにそのディレクトリが存在しない場合は、自動的に作成されます。

プロジェクトディレクトリの場所

環境変数 PROJECT_HOME は、virtualenvwrapper が使うプロジェクトのワークディレクトリの場所を指定します。この環境変数は mkproject を利用する前に設定して、そのディレクトリを作成しておく必要があります。

プロジェクトのリンクファイル名

環境変数 VIRTUALENVWRAPPER_PROJECT_FILENAME は、virtualenvwrapper が使う、プロジェクトのワークディレクトリに対して virtualenv をリンクするファイル名を指定します。

フックスクリプトの場所

環境変数 VIRTUALENVWRAPPER_HOOK_DIR は、virtualenvwrapper が使う ユーザー定義のフック が保存される場所を指定します。デフォルト設定 $WORKON_HOME です。

フックログの場所

環境変数 VIRTUALENVWRAPPER_LOG_DIR は、virtualenvwrapper のフックローダーが書き込むログの場所を指定します。デフォルト設定 $WORKON_HOME です。

Python インタープリターと virtualenv と $PATH

起動ファイルの読み込み時に virtualenvwrapper.sh は、最初に $PATH 上の pythonvirtualenv を見つけて、後で使うためにその情報を覚えておきます。これは virtualenvwrapper がインストールされていない、または別のバージョンの virtualenv がインストールされた仮想環境内部でインタープリタを有効にしていながら $PATH 変更による競合が起こらないようにします。この動作の理由は virtualenvwrapper.sh を source する 前に 設定された $PATH が重要だからです。

例えば:

export PATH=/usr/local/bin:$PATH
source /usr/local/bin/virtualenvwrapper.sh

$PATH の探索を上書きするには、 利用するインタープリターのフルパスを指定した VIRTUALENVWRAPPER_PYTHON と、 利用する virtualenv バイナリ指定した VIRTUALENVWRAPPER_VIRTUALENV のフルパスを設定してください。 両方の環境変数は virtualenvwrapper.sh が source される前に 設定する必要があります

例えば:

export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv
source /usr/local/bin/virtualenvwrapper.sh
virtualenv のデフォルト引数

VIRTUALENVWRAPPER_VIRTUALENV で指定されたアプリケーションが引数を取るなら、その引数を VIRTUALENVWRAPPER_VIRTUALENV_ARGS に設定できます。この環境変数は virtualenv に渡すデフォルト引数を設定するのにも使えます。例えば、システムの site-packages ディレクトリと独立した仮想環境を毎回新たに作成するには、 --no-site-packages をその値として設定します。

export VIRTUALENVWRAPPER_VIRTUALENV_ARGS='--no-site-packages'
一時ファイル

virtualenvwrapper は $TMPDIR に一時ファイルを作成します。その環境変数がセットされていない場合は /tmp を使用します。virtualenvwrapper 向けだけの一時ファイルの作成場所を変更するには VIRTUALENVWRAPPER_TMPDIR をセットしてください。

サイト全体の設定

ほとんどの UNIX システムは、全てのユーザーに設定を適用する機能を提供します。これは典型的に2つの方法のいずれかを取ります。新しいアカウントの作成時の skeleton ファイルを編集するか、シェルのグローバルな起動ファイルを編集するかです。

新しいアカウントの作成時にスケルトンファイルを編集する方法は、各ユーザーが virtualenvwrapper を読み込むようにあらかじめ設定された自分たちの起動ファイルをもちます。各ユーザーは、起動ファイルの該当行をコメントアウトしたり、削除することで設定を無効にできます。編集する必要のある適切なファイルを把握するには、オペレーティングシステム、またはシェルのドキュメントを参照してください。

特定シェルのグローバルの起動ファイルを変更する方法は、そのシェルの全ユーザーに対して virtualenvwrapper が有効となり、各ユーザーが無効にすることはできません。編集する必要のある適切なファイルを把握するには、オペレーティングシステム、またはシェルのドキュメントを参照してください。

2.9 へのアップグレード

バージョン 2.9 は、それまで別で配布していた virtualenvwrapper.project の機能を提供します。そのプロジェクト拡張の古いバージョンをインストールしているなら、アップグレード前にそれらを削除してください。

1.x からのアップグレード

ラッパー関数を含むシェルスクリプトは 2.x バージョンで bash 以外のシェルをサポートするためにその名前が変更されました。あなたの起動ファイルの source /usr/local/bin/virtualenvwrapper_bashrcsource /usr/local/bin/virtualenvwrapper.sh へ変更してください。

コマンドリファレンス

全てのコマンドは次のようにターミナル上で使用されます。

仮想環境を管理する

mkvirtualenv

WORKON_HOME に新たな仮想環境を作成します。

構文:

mkvirtualenv [-a project_path] [-i package] [-r requirements_file] [virtualenv options] ENVNAME

-a, -i, -r, -h を除いた全てのコマンドラインオプションは virtualenv へ直接的に渡されます。新しい仮想環境は初期化された後に自動的にアクティブ化されます。

$ workon
$ mkvirtualenv mynewenv
New python executable in mynewenv/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(mynewenv)$ workon
mynewenv
(mynewenv)$

-a オプションは、既存のプロジェクトディレクトリに新しい環境を関連付けるのに使います。

-i オプションは、その環境を作成した後に指定したパッケージをインストールできます (このオプションを繰り返し使うことで複数のパッケージもインストールできます) 。

-r オプションは、インストールしたいパッケージ一覧を保存したテキストファイルを指定するのに使います。この引数のファイル名は pip -r へ渡されてインストールが行われます。

mktmpenv

WORKON_HOME ディレクトリに新しい環境を作成します。

構文:

mktmpenv [VIRTUALENV_OPTIONS]

一意な名前をもつ virtualenv 環境が生成されます。

$ mktmpenv
Using real prefix '/Library/Frameworks/Python.framework/Versions/2.7'
New python executable in 1e513ac6-616e-4d56-9aa5-9d0a3b305e20/bin/python
Overwriting 1e513ac6-616e-4d56-9aa5-9d0a3b305e20/lib/python2.7/distutils/__init__.py
with new content
Installing distribute...............................................
....................................................................
.................................................................done.
This is a temporary environment. It will be deleted when deactivated.
(1e513ac6-616e-4d56-9aa5-9d0a3b305e20) $
lsvirtualenv

全ての仮想環境を表示します。

構文:

lsvirtualenv [-b] [-l] [-h]
-b ブリーフモード、冗長な出力を無効にする
-l ロングモード、冗長な出力を有効にする(デフォルト)
-h lsvirtualenv のヘルプを表示する

See also

showvirtualenv

1つの仮想環境の詳細を表示します。

構文:

showvirtualenv [env]

See also

rmvirtualenv

WORKON_HOME の仮想環境を削除します。

構文:

rmvirtualenv ENVNAME

カレントの仮想環境を削除する前に deactivate を実行しなければなりません。

(mynewenv)$ deactivate
$ rmvirtualenv mynewenv
$ workon
$
cpvirtualenv

WORKON_HOME の仮想環境を複製します。

構文:

cpvirtualenv ENVNAME TARGETENVNAME

Note

コピー操作で作成された仮想環境は 再配置可能 です。

$ workon
$ mkvirtualenv source
New python executable in source/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(source)$ cpvirtualenv source dest
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install relative
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install-2.6 relative
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/pip relative
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postdeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/preactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/predeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
(dest)$ workon
dest
source
(dest)$

アクティブな仮想環境を制御する

workon

作業する仮想環境を変更、または表示します。

構文:

workon [environment_name]

environment_name が与えられない場合は標準出力に利用可能な仮想環境を表示します。

$ workon
$ mkvirtualenv env1
  New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ mkvirtualenv env2
New python executable in env2/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env2)$ workon
env1
env2
(env2)$ workon env1
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ workon env2
(env2)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env2
(env2)$
deactivate

仮想環境からシステムにインストールされた Python のバージョンに切り替えます。

構文:

deactivate

Note

このコマンドは、実際は virtualenv の一部ですが、まさに workon が行うようにアクティブ化のために、処理の前後にフック機能を提供するためにラップされます。

$ workon
$ echo $VIRTUAL_ENV

$ mkvirtualenv env1
New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ deactivate
$ echo $VIRTUAL_ENV

$

仮想環境へ簡単に移動する

カレントのアクティブ化された仮想環境内へ移動するためのショートカットを提供する2つの機能があります。

cdvirtualenv

$VIRTUAL_ENV へカレントワークディレクトリを移動します。

構文:

cdvirtualenv [subdir]

cdvirtualenv を呼び出すと、カレントワークディレクトリを仮想環境($VIRTUAL_ENV)のトップへ移動します。オプションの引数はそのパスに追加されて、サブディレクトリへ直接的に移動することもできます。

$ mkvirtualenv env1
New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdvirtualenv
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdvirtualenv bin
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/bin
cdsitepackages

$VIRTUAL_ENVsite-packages へカレントワークディレクトリを移動します。

構文:

cdsitepackages [subdir]

仮想環境の site-packages ディレクトリへの正確なパスは Python のバージョンに依存するので、 cdsitepackagescdvirtualenv lib/python${pyvers}/site-packages のショートカットです。さらにオプションの引数は直接移動する site-packages 内の階層構造のディレクトリを指定することもできます。

$ mkvirtualenv env1
New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdsitepackages PyMOTW/bisect/
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/lib/python2.6/site-packages/PyMOTW/bisect
lssitepackages

lssitepackages を呼び出すと、カレントのアクティブ化された仮想環境の site-packages ディレクトリのコンテンツを表示します。

構文:

lssitepackages
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ $ workon env1
(env1)$ lssitepackages
distribute-0.6.10-py2.6.egg     pip-0.6.3-py2.6.egg
easy-install.pth                setuptools.pth

パス管理

add2virtualenv

カレントのアクティブ化された仮想環境の Python パスへ指定したディレクトリを追加します。

構文:

add2virtualenv directory1 directory2 ...

システムの site-pacakges ディレクトリに存在しないインストール済みのパッケージやそれぞれの仮想環境にインストールしたくないパッケージを共有したいときがあります。1つの解決方法はその仮想環境の site-packages ディレクトリへシンボリックリンクを張ることです。しかし、 add2virtualenv を使用して site-packages 内の .pth ファイルへそういったパッケージを含めることで、PYTHONPATH へ拡張ディレクトリを追加することも簡単です。

  1. Django のような、大きなプロジェクトのソースをチェックアウトする
  2. add2virtualenv path_to_source を実行する
  3. add2virtualenv を実行する
  4. 使用方法とカレントの “拡張された” パスリストが表示される

site-packages ディレクトリ内の virtualenv_path_extensions.pth と名付けられたパスファイルへそのディレクトリ名が追加されます。

James Bennett と Jannis Leidel から提供されたものに基づいています。

toggleglobalsitepackages

アクティブな virtualenv が、グローバルの Python site-packages ディレクトリにあるパッケージにアクセスさせるかどうかを制御します。

構文:

toggleglobalsitepackages [-q]

実行すると virtualenv の更新後の状態を表示します。非表示にするには -q を指定してください。

$ mkvirtualenv env1
New python executable in env1/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
(env1)$ toggleglobalsitepackages
Disabled global site-packages
(env1)$ toggleglobalsitepackages
Enabled global site-packages
(env1)$ toggleglobalsitepackages -q
(env1)$

プロジェクトディレクトリの管理

mkproject

PROJECT_HOME にプロジェクトディレクトリと WORKON_HOME に新しい virtualenv を作成します。

構文:

mkproject [-t template] [virtualenv_options] ENVNAME

テンプレートオプションは、新しいプロジェクトを作成するのに使うテンプレートを複数指定できます。テンプレートはコマンドラインで指定した順番で適用されます。その他の全てのオプションは、プロジェクトと同じ名前をもつ仮想環境を作成するために mkvirtualenv に渡されます。

$ mkproject myproj
New python executable in myproj/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj)$ pwd
/Users/dhellmann/Devel/myproj
(myproj)$ echo $VIRTUAL_ENV
/Users/dhellmann/Envs/myproj
(myproj)$
setvirtualenvproject

既存の virtualenv を既存のプロジェクトに束縛します。

構文:

setvirtualenvproject [virtualenv_path project_path]

setvirtualenvproject への引数は、virtualenv とプロジェクトディレクトリへのフルパスです。仮想環境のアクティブ化を workon で行うときに、そのプロジェクトもアクティブ化されるように連携します。

$ mkproject myproj
New python executable in myproj/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj)$ mkvirtualenv myproj_new_libs
New python executable in myproj/bin/python
Installing distribute.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj_new_libs)$ setvirtualenvproject $VIRTUAL_ENV $(pwd)

引数を指定しない場合は、カレントの virtualenv とカレントディレクトリが指定されたと見なします。

任意の数の virtualenv が、Python またはその他のテスト向けの依存関係をもったバージョン間で切り替えやすいように、同じプロジェクトディレクトリを参照できます。

cdproject

カレントのワークディレクトリから、アクティブな virtualenv のプロジェクトディレクトリとして指定したディレクトリに変更します。

構文:

cdproject

virtualenvwrapper をカスタマイズする

virtualenvwrapper は仮想環境を作成・削除したり、環境間を移動したりするときに、設定内容、シェル環境またはその他の設定値を変更できる複数のフックポイントを追加します。そういったフック機能は2つの方法で提供されています。

ユーザカスタマイズ

エンドユーザのカスタマイズスクリプトは 読み込み (シェル環境を変更できる) されるか、適切な条件で外部プログラムのように 実行 されるかのどちらかです。

全ての環境に適用されるグローバルスクリプトは、 VIRTUALENVWRAPPER_HOOK_DIR で指定したディレクトリに置きます。ローカルスクリプトは virtualenv の bin ディレクトリに置きます。

get_env_details
グローバル/ローカル:両方
引数:環境名
読み込み/実行:実行

$VIRTUALENVWRAPPER_HOOK_DIR/get_env_detailsworkon が引数無しで実行されるときに実行されます。そして、仮想環境のリストを表示します。仮想環境の名前が表示された後で、そのフックは環境毎に一度実行されて、その環境に関する追加情報を表示します。

initialize
グローバル/ローカル:グローバル
引数:無し
読み込み/実行:読み込み

あなたの環境に virtualenvwrapper.sh を読み込むときに $VIRTUALENVWRAPPER_HOOK_DIR/initialize が読み込まれます。virtualenvwrapper が有効になるときにグローバルな設定を調整するために使用してください。

premkvirtualenv
グローバル/ローカル:グローバル
引数:新しい環境名
読み込み/実行:実行

$VIRTUALENVWRAPPER_HOOK_DIR/premkvirtualenv は仮想環境が作成された後で外部プログラムのように実行されますが、カレントの環境が新しい環境へ切り替わる前に実行されます。そのスクリプトのカレントワークディレクトリは $WORKON_HOME で、そのスクリプトへの引数として新しい環境の名前が渡されます。

postmkvirtualenv
グローバル/ローカル:グローバル
引数:無し
読み込み/実行:読み込み

$VIRTUALENVWRAPPER_HOOK_DIR/postmkvirtualenv は、新しい環境が作成されてアクティブ化された後で読み込まれます。 -a <project_path> フラグを指定された場合、このスクリプトを読み込む前にプロジェクトディレクトリへのリンクを設定します。

precpvirtualenv
グローバル/ローカル:グローバル
引数:オリジナルの環境名、新しい環境名
読み込み/実行:実行

$VIRTUALENVWRAPPER_HOOK_DIR/precpvirtualenv は元の環境が複製されて再配置可能になるときに外部プログラムのように実行されますが、 premkvirtualenv フックが実行される前、もしくはカレントの環境が新しい環境へ切り替わる前に実行されます。そのスクリプトのカレントワークディレクトリは $WORKON_HOME で、そのスクリプトへの引数として元の環境名と新しい環境名が渡されます。

postcpvirtualenv
グローバル/ローカル:グローバル
引数:無し
読み込み/実行:読み込み

$VIRTUALENVWRAPPER_HOOK_DIR/postcpvirtualenv は新しい環境が作成されてアクティブ化された後で読み込まれます。

preactivate
グローバル/ローカル:グローバル、ローカル
引数:環境名
読み込み/実行:実行

グローバルの $VIRTUALENVWRAPPER_HOOK_DIR/preactivate スクリプトは新しい仮想環境が有効になる前に実行されます。その環境名は1番目の引数として渡されます。

ローカルの $VIRTUAL_ENV/bin/preactivate フックは新しい仮想環境が有効になる前に実行されます。その環境名は1番目の引数として渡されます。

postactivate
グローバル/ローカル:グローバル、ローカル
引数:無し
読み込み/実行:読み込み

グローバルの $VIRTUALENVWRAPPER_HOOK_DIR/postactivate スクリプトは新しい仮想環境が有効になった後で読み込まれます。 $VIRTUAL_ENV はそのスクリプトが実行されるときに新しい環境を参照します。

このサンプルスクリプトは _OLD_VIRTUAL_PS1 を使用して仮想環境の名前と古い PS1 名前の間にスペースを追加します。

PS1="(`basename \"$VIRTUAL_ENV\"`) $_OLD_VIRTUAL_PS1"

ローカルの $VIRTUAL_ENV/bin/postactivate スクリプトは新しい仮想環境が有効になった後で読み込まれます。 $VIRTUAL_ENV はそのスクリプトが実行されるときに新しい環境を参照します。

この PyMOTW 環境のサンプルは PyMOTW に含まれるソースツリーを参照して PATH 変数とカレントワークディレクトリを変更します。

pymotw_root=/Users/dhellmann/Documents/PyMOTW
cd $pymotw_root
PATH=$pymotw_root/bin:$PATH
predeactivate
グローバル/ローカル:グローバル、ローカル
引数:無し
読み込み/実行:読み込み

ローカルの $VIRTUAL_ENV/bin/predeactivate スクリプトはカレントの仮想環境が非アクティブ化される前に読み込まれます。そして、あなたの環境の設定をクリアしたり、無効にするために使用されます。 $VIRTUAL_ENV はそのスクリプトが実行されるときに古い環境を参照します。

グローバルの $VIRTUALENVWRAPPER_HOOK_DIR/predeactivate スクリプトはカレントの仮想環境が非アクティブ化される前に読み込まれます。 $VIRTUAL_ENV はそのスクリプトが実行されるときに古い環境を参照します。

postdeactivate
グローバル/ローカル:グローバル、ローカル
引数:無し
読み込み/実行:読み込み

$VIRTUAL_ENV/bin/postdeactivate スクリプトはカレントの仮想環境が非アクティブ化される前に読み込まれます。そして、あなたの環境の設定をクリアしたり、無効にするために使用されます。非アクティブ化される環境へのパスは $VIRTUALENVWRAPPER_LAST_VIRTUALENV でのみ有効です。

prermvirtualenv
グローバル/ローカル:グローバル
引数:環境名
読み込み/実行:実行

$VIRTUALENVWRAPPER_HOOK_DIR/prermvirtualenv スクリプトは仮想環境が削除される前に外部コマンドのように実行されます。そのスクリプトへの引数としてその環境のディレクトリに対するフルパスが渡されます。

postrmvirtualenv
グローバル/ローカル:グローバル
引数:環境名
読み込み/実行:実行

$VIRTUALENVWRAPPER_HOOK_DIR/postrmvirtualenv スクリプトは仮想環境が削除された後で外部コマンドのように実行されます。そのスクリプトへの引数としてその環境のディレクトリに対するフルパスが渡されます。

premkproject
グローバル/ローカル:グローバル
引数:新しいプロジェクト名
読み込み/実行:実行

$WORKON_HOME/premkproject は、仮想環境が作成されてカレントの環境が新しい環境を指すように切り替わった後で、外部プログラムとして実行されます。 但し、そのタイミングは新しいプロジェクトディレクトリが作成される前です。 このスクリプトのカレントのワークディレクトリは $PROJECT_HOME となり、新しいプロジェクト名がこのスクリプトの引数として渡されます。

postmkproject
グローバル/ローカル:グローバル
引数:無し
読み込み/実行:読み込み

$WORKON_HOME/postmkproject は、新しい環境とプロジェクトディレクトリが作成されて virtualenv がアクティブ化された後で読み込まれます。カレントのワークディレクトリはプロジェクトディレクトリです。

virtualenvwrapper を拡張する

開発環境をカスタマイズするために自作で解決してきた長い経験から、共通タスクを自動化して、何度も繰り返す苛々するような作業を取り除く機能がどれほどの価値をもつか分かりました。大工は治具を組み立て、ソフトウェア開発者はシェルスクリプトを書きます。virtualenvwrapper は逆になりますが、求める方法で動作するようにツールを修正する職人を励ます伝統を受け継いでいます。

繰り返し行う手動の操作を取り除いたり開発ワークフローを効率化するために提供されるフックを使用してください。例えば、最後に編集されたセッションからファイルを再読み込みするために IDE にプロジェクトファイルを読む込ませる、時間追跡記録を管理する、もしくはアプリケーションサーバの開発バージョンを起動・停止するために pre_activatepost_activate フックを設定してください。 initialize は virtualenvwrapper に対するフックや完全に新しいコマンドを追加するためのフックです。そして pre_mkvirtualenvpost_mkvirtualenv といったフックはそれぞれの新しい開発環境へ基本的な必需品をインストールする、ソースコードリポジトリの初期化、その他の新たなプロジェクトの設定を行うといった機会を与えます。

virtualenvwrapper がそういったことを実行できるようにあなたのコードをアタッチする方法が2つあります。エンドユーザはシェルスクリプトか、個人的なカスタマイズを施したプログラムを使用できます(ユーザカスタマイズ を参照)。さらに拡張機能は、システムと開発者間で共通の振る舞いを共有できるようにする Distribute エントリポイント を使用して Python で実装することもできます。

拡張機能を定義する

Note

virtualenvwrapper はユーザのカスタムスクリプトを作成して実行することをプラグインで実現します(user_scripts)。次のサンプルはそういったプラグインの実装を紹介します。

コードの構成

virtualenvwrapper の Python パッケージは 名前空間パッケージ です。複数のライブラリが一緒に配布されていなかったり同じディレクトリ内にインストールされていなかったとしても、そのパッケージ内へインストールできます。拡張機能は次のようにソースツリーを設定することで virtualenvwrapper の名前空間を(オプションで)使用することが出来ます。

  • virtualenvwrapper/
    • __init__.py
    • user_scripts.py

そして __init__.py に次のコードを含めます。

"""virtualenvwrapper module
"""

__import__('pkg_resources').declare_namespace(__name__)

Note

拡張機能はどんなパッケージからも読み込まれるので virtualenvwrapper の名前空間を使用する必要はありません。

拡張 API

パッケージを作成した後の次のステップとして、拡張コードを保持するモジュールを作成します。例えば virtualenvwrapper/user_scripts.py です。そのモジュールは実際の拡張機能のエントリポイントを含みます。サポートするコードが含められるか、標準の Python コードの構成テクニックを利用してインポートされます。

API は全ての拡張ポイントで同じです。それぞれは1つの引数、つまりコマンドライン上でフックローダへ渡される文字列のリストを受け取る Python 関数を使用します。

def function_name(args):
    # args is a list of strings passed to the hook loader

引数リストのコンテンツは次の拡張ポイント毎に定義されます(拡張ポイント を参照)。

拡張機能の起動
ダイレクトアクション

プラグインは2つの方法でそれぞれのフックをアタッチできます。デフォルトは直接的に何らかの処理を実行する関数を持ちます。例えば、ユーザスクリプトプラグインの initialize() 関数は virtualenvwrapper.sh が読み込まれるときにデフォルトユーザスクリプトを作成します。

def initialize(args):
    for filename, comment in GLOBAL_HOOKS:
        make_hook(os.path.join('$WORKON_HOME', filename), comment)
    return
ユーザ環境を変更する

拡張機能がユーザ環境のアップデートを必要とするケースがあります(例えば、カレントワークディレクトリを変更したり、環境変数を設定する等)。ユーザ環境に対する変更はユーザのカレントシェル内で行われなければならず、独立したプロセスで実行できません。ユーザのシェルプロセスで実行するコードを持つために、拡張機能は実行されるシェル構文のテキストを返すフック関数を定義できます。これらの source フックは同じ名前を持つ通常のフックの後で実行されます。そして、そのフック内部で処理を行ってはいけません。

ユーザスクリプトプラグインの initialize_source() フックは、グローバルな初期化スクリプトを調べてカレントのシェルプロセスでそのスクリプトを実行させます。

def initialize_source(args):
    return """
#
# Run user-provided scripts
#
[ -f "$WORKON_HOME/initialize" ] && source "$WORKON_HOME/initialize"
"""

Warning

拡張機能はユーザのワークシェルを変更しているので、予期しない既存変数の上書きにより環境が汚染されないように注意しなければなりません。できるだけ一時的な変数を作成せずに、必要なところで一意な名前を使用してください。接頭辞として拡張名が付く変数は名前空間を管理するのに良い方法です。例えば、 temp_file ではなく user_scripts_temp_file を使用してください。一時的な変数は必要なくなったときに unset で解放してください。

Warning

virtualenvwrapper は構文が少し違う複数のシェル(bash, sh, zsh, ksh)で動作します。ソースフックを定義するときにアカウント内にこの移植性を考慮してください。最も簡単な構文のみを使用することで普通は問題ありませんが、求める結果を得るためには唯一の方法しかないケースにおいて、違う構文を生成する SHELL 環境変数を調べる可能性があります。

エントリポイントを登録する

プラグインで定義された関数は virtualenvwrapper のフックローダが見つけられるために エントリポイント として登録する必要があります。 Distribute エントリポイントは関数を実装するパッケージでその関数に対するエントリポイントの名前をマッピングすることにより、そのパッケージの setup.py で設定されます。

この virtualenvwrapper の setup.py の一部は initialize()initialize_source() エントリポイントの設定方法を説明します。

# Bootstrap installation of Distribute
import distribute_setup
distribute_setup.use_setuptools()

from setuptools import setup

setup(
    name = 'virtualenvwrapper',
    version = '2.0',

    description = 'Enhancements to virtualenv',

    # ... details omitted ...

    namespace_packages = [ 'virtualenvwrapper' ],

    entry_points = {
        'virtualenvwrapper.initialize': [
            'user_scripts = virtualenvwrapper.user_scripts:initialize',
            ],
        'virtualenvwrapper.initialize_source': [
            'user_scripts = virtualenvwrapper.user_scripts:initialize_source',
            ],

        # ... details omitted ...
        },
    )

setup() への entry_points 引数はエントリポイントの指定子を表示するエントリポイント グループ名 をマッピングするディクショナリです。違うグループ名はそれぞれの拡張ポイントのために virtualenvwrapper により定義されます(拡張ポイント を参照)。

エントリポイント指定子は name = package.module:function という構文の文字列です。慣例からエントリポイントの 名前 はプラグインの名前を付けますが、必須だというわけではありません (その名前を使わなくても構いません) 。

フックローダ

拡張機能は virtualenvwrapper.hook_loader で実装されたコマンドラインアプリケーションを通して実行されます。 virtualenvwrapper.sh がプライマリの呼び出しであり、ユーザはそのアプリケーションを直接的に実行する必要はないので、分割されたスクリプトはインストールされません。その代わり、そのアプリケーションを実行するにはインタープリタに -m オプションを指定してください。

$ python -m virtualenvwrapper.hook_loader -h
Usage: virtualenvwrapper.hook_loader [options] <hook> [<arguments>]

Manage hooks for virtualenvwrapper

Options:
  -h, --help            show this help message and exit
  -s, --source          Print the shell commands to be run in the current
                        shell
  -l, --list            Print a list of the plugins available for the given
                        hook
  -v, --verbose         Show more information on the console
  -q, --quiet           Show less information on the console
  -n NAMES, --name=NAMES
                        Only run the hook from the named plugin

initialize フックのためにその拡張機能を実行するには次のようにします。

$ python -m virtualenvwrapper.hook_loader -v initialize

initialize フックのためにシェルコマンドを読み込むには次のようにします。

$ python -m virtualenvwrapper.hook_loader --source initialize

実際は、フックローダが直接フックを実行するよりも両方のモードでフックを実行するシェル関数 virtualenvwrapper_run_hook を使用する方がもっと便利です。

$ virtualenvwrapper_run_hook initialize

シェル関数に与えられた全ての引数はフックローダへ直接渡されます。

ロギング

フックローダはログメッセージを $WORKON_HOME/hook.log に書き込むように設定します。またログメッセージは冗長フラグにより標準エラーにも出力されます。デフォルトでは、ログメッセージは info かそれ以上のレベルが標準エラーへ出力され、 debug かそれ以上がログファイルへ書き込まれます。この方法でロギングを使用することでユーザに拡張機能の冗長性を制御する便利な仕組みを提供します。

拡張機能からロギングを使用するには、単純にロガーをインスタンス化して、ログメッセージと共にその info(), debug() やその他のメソッドを呼び出してください。

import logging
log = logging.getLogger(__name__)

def pre_mkvirtualenv(args):
    log.debug('pre_mkvirtualenv %s', str(args))
    # ...
拡張ポイント

ネイティブプラグインの拡張ポイントの名前は複数のパートを持つ命名規則 virtualenvwrapper.(pre|post)_<event>[_source] に従います。 <event> は拡張機能が引き起こす virtualenvwrapper またはユーザによるアクションです。 (pre|post) はその拡張機能の呼び出しがイベントの前か後かのどちらかを指します。接尾辞 _source は直接アクションを受け取らずにシェルスクリプトのコードを返す拡張機能に追加されます(ユーザ環境を変更する を参照)。

get_env_details

virtualenvwrapper.get_env_details フックは workon が引数無しで実行されるときに実行されます。そして、仮想環境のリストを表示します。仮想環境の名前が表示された後で、そのフックは環境毎に一度実行されて、その環境に関する追加情報を表示します。

initialize

virtualenvwrapper.initialize フックは virtualenvwrapper.sh が環境に読み込まれる毎に実行されます。initialize フックは設定ファイルのテンプレートをインストールしたり、適切なプラグイン操作のためにシステムを整備するために使用されます。

pre_mkvirtualenv

virtualenvwrapper.pre_mkvirtualenv フックは仮想環境が作成された後で実行されますが、新しい環境がアクティブ化される前に実行されます。そのフックが実行されるときのためにカレントワークディレクトリは $WORKON_HOME で、1つの引数として新しい環境の名前が渡されます。

post_mkvirtualenv

virtualenvwrapper.post_mkvirtualenv フックは新しい仮想仮想が作成されて、アクティブ化された後で実行されます。 $VIRTUAL_ENV は新しい環境を指すようにセットされます。

pre_activate

virtualenvwrapper.pre_activate フックは仮想環境が有効になる前に実行されます。環境の名前は1番目の引数として渡されます。

post_activate

virtualenvwrapper.post_activate フックは仮想環境が有効になった後で実行されます。 $VIRTUAL_ENV はカレント環境を指すようにセットされます。

pre_deactivate

virtualenvwrapper.pre_deactivate フックは仮想環境が無効になる前に実行されます。 $VIRTUAL_ENV はカレント環境を指すようにセットされます。

post_deactivate

virtualenvwrapper.post_deactivate フックは仮想環境が無効になった後で実行されます。非アクティブ化される環境の名前は1番目の引数として渡されます。

pre_rmvirtualenv

virtualenvwrapper.pre_rmvirtualenv フックは仮想環境が削除される前に実行されます。削除される環境の名前は1番目の引数として渡されます。

post_rmvirtualenv

virtualenvwrapper.post_rmvirtualenv フックは仮想環境が削除された後で実行されます。削除される環境の名前は1番目の引数として渡されます。

新しい拡張ポイントを追加する

さらに新しい操作を定義するプラグインは新しい拡張ポイントも定義できます。フックローダが拡張機能を見つけるために行う設定は必要ありません。名前を記述して virtualenvwrapper_run_hook の呼び出しを追加することで、追加した拡張機能が実行されるようになります。

フックローダは全ての拡張ポイントの名前が virtualenvwrapper. で始まることを前提としています。そして、新しいプラグインは独自の名前空間の修飾語句をその接頭辞に追加したくなるでしょう。例えば project 拡張はプロジェクトのディレクトリ作成(前後)に関連して新たなイベントを定義します。そこで virtualenvwrapper.project.pre_mkprojectvirtualenvwrapper.project.post_mkproject が呼び出されます。それは次のように1つずつ実行されます。

virtualenvwrapper_run_hook project.pre_mkproject $project_name

virtualenvwrapper_run_hook project.post_mkproject

です。

プロジェクト管理

project directory は virtualenv に関連付けられますが、開発を支援するために必要とされるコンポーネントをインストールするというより、普通は活発に開発中のソースコードを含みます。例えば、プロジェクトディレクトリは、バージョン管理システムからチェックアウトされたソースコード、まだバージョン管理システムにコミットされていないテストや実験的なファイルから作成された一時的なファイルを含むかもしれません。

プロジェクトディレクトリが作成して、 mkvirtualenv の代わりに mkproject を実行するときに virtualenv を束縛します。既存のプロジェクトディレクトリを virtualenv に束縛するには setvirtualenvproject を使ってください。

テンプレートの利用

新しいプロジェクトディレクトリは、空のディレクトリ、または template プラグインを使って作成されます。テンプレートは mkproject の引数として指定します。複数のテンプレートも適用できます。例えば、bitbucket のプロジェクトから Mercurial リポジトリをチェックアウトして新たに Django サイトを作成するには、 bitbucketdjango のテンプレートを組み合わせて使います。

$ mkproject -t bitbucket -t django my_site

Tips とトリック

これは virtualenv と virtualenvwrapper をさらに使い易くするためにユーザが教えてくれた tips です。あなたが共有したい tip を持っているなら、私にメールを送ってもらうか、 このブログ にコメントをください。私はこのページにその tip を追加します。

zsh プロンプト

Nat からです。

zsh を使用して、アクティブな仮想環境をスクリーンの右側に表示するために $WORKON_HOME/post(de)activate に少し追加しました。

postactivate は次になります。

PS1="$_OLD_VIRTUAL_PS1"
_OLD_RPROMPT="$RPROMPT"
RPROMPT="%{${fg_bold[white]}%}(env: %{${fg[green]}%}`basename \"$VIRTUAL_ENV\"`%{${fg_bold[white]}%})%{${reset_color}%} $RPROMPT"

そして postdeactivate は次になります。

RPROMPT="$_OLD_RPROMPT"

個人的な趣向や環境に応じて色を調整してください。

キャッシュされた $PATH エントリを更新する

Nat からです。

さらに zsh は新たなパスをすぐに取得しない問題があったので $WORKON_HOME/postactivate$WORKON_HOME/postdeactivate へコマンド ‘rehash’ も追加しました。

pip の virtualenv サポート

http://becomingguru.com/ からです。

virtualenvwrapper として virtualenvs のために pip が同じディレクトリを使用するようにログインシェルに次の内容を追加してください。

export PIP_VIRTUALENV_BASE=$WORKON_HOME

さらに Nat からです。

becomingguru が指摘したことに加えて次の行がキーになります。

export PIP_RESPECT_VIRTUALENV=true

それは -E パラメータを pip へ渡さずに pip がアクティブな仮想環境を検出してインストールします。

プロジェクトのワークディレクトリを作成する

James からです。

私は postmkvirtualenv スクリプトでプロジェクト名に基づいてディレクトリを作成して、 Python パスへそのディレクトリを追加してからそこへ移動します。

proj_name=$(echo $VIRTUAL_ENV|awk -F'/' '{print $NF}')
mkdir $HOME/projects/$proj_name
add2virtualenv $HOME/projects/$proj_name
cd $HOME/projects/$proj_name

私は postactivate スクリプトで workon コマンドを使用するときに自動的にプロジェクトディレクトリへ移動するようにセットします。

proj_name=$(echo $VIRTUAL_ENV|awk -F'/' '{print $NF}')
cd ~/projects/$proj_name

ディレクトリへ移動したときに自動的に workon を実行する

cd を実行する毎にそのディレクトリでシェル環境を調べるように追加したコードを Justin Lily が投稿しました.venv ファイルを見つけたら、そのファイルに含まれる環境の名前でアクティブ化します。そのディレクトリから移動すると、カレントの仮想環境は自動的に非アクティブ化します。

Harry Marrgit リポジトリ で動作するよく似た機能を書きました。

新しい環境に共通ツールを自動的にインストールする

rizumu からです。

私はこの postmkvirtualenv を基本的なセットアップを行うインストールに使用します。

$ cat postmkvirtualenv
#!/usr/bin/env bash
curl -O http://python-distribute.org/distribute_setup.p... />python distribute_setup.py
rm distribute_setup.py
easy_install pip==dev
pip install Mercurial

それから、私の開発ツールと共に pip の要求ファイルを持ちます。

$ cat developer_requirements.txt
ipdb
ipython
pastescript
nose
http://douglatornell.ca/software/python/Nosy-1.0.tar.gz
coverage
sphinx
grin
pyflakes
pep8

それぞれのプロジェクトは PIL, psycopg2, django-apps, numpy といったその独自の pip 要求ファイルを持ちます。

cd のデフォルトの振る舞いを変更する

mae からです。

これは workon の後で実行することになる postactivate フックです。venv ルートへ移動する ~cd で移動する代わりに VENV を知っているように cd を基本的に上書きします。IMO はとても扱い易くて、もうそれなしでは生きていけません。適切なパスが渡されると正常に移動します。

cd () {
    if (( $# == 0 ))
    then
        builtin cd $VIRTUAL_ENV
    else
        builtin cd "$@"
    fi
}

cd

開発者向け

あなたが直接 virtualenvwrapper に貢献したいなら、次の説明が役に立つでしょう。パッチ、バグレポートや機能要求は BitBucket サイト で歓んで受け付けます。パッチや pull リクエストによる貢献はその修正を取り込んだり、優先度の配慮も行い易いでしょう。

Note

virtualenvwrapper のコアへ新しい機能を追加する前に、その代わりに機能拡張として実装すべきかどうかをよく考えてください。

ドキュメントを作成する

virtualenvwrapper のドキュメントは reStructuredText で書かれていて Sphinx で HTML に変換されます。それは make コマンドでビルドされます。ドキュメントをビルドするために次のパッケージが必要になります。

  • Sphinx
  • docutils

全てのツールが pip を使用して仮想環境内にインストールされたら、ドキュメントの HTML バージョンを生成するために make html を実行してください。

$ make html
rm -rf virtualenvwrapper/docs
(cd docs && make html SPHINXOPTS="-c sphinx/pkg")
sphinx-build -b html -d build/doctrees  -c sphinx/pkg source build/html
Running Sphinx v0.6.4
loading pickled environment... done
building [html]: targets for 2 source files that are out of date
updating environment: 0 added, 2 changed, 0 removed
reading sources... [ 50%] command_ref
reading sources... [100%] developers

looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 33%] command_ref
writing output... [ 66%] developers
writing output... [100%] index

writing additional files... search
copying static files... WARNING: static directory '/Users/dhellmann/Devel/virtualenvwrapper/plugins/docs/sphinx/pkg/static' does not exist
done
dumping search index... done
dumping object inventory... done
build succeeded, 1 warning.

Build finished. The HTML pages are in build/html.
cp -r docs/build/html virtualenvwrapper/docs

最終的なドキュメントの生成内容はサンドボックスの ./virtualenvwrapper/docs にあります。

テストを実行する

virtualenvwrapper のテストスイートは shunit2tox を使います。shunit2 のソースは tests ディレクトリに含まれていますが、tox は別途インストールする必要があります (pip install tox) 。

bash, zsh, ksh 環境で Python 2.4 - 2.7 のテストを実行するには、hg リポジトリの最上位ディレクトリから tox を実行してください。

個別のテストスクリプトを実行するには、次のように実行します。

$ tox tests/test_cd.sh

Python のあるバージョンでテストを実行するには、tox を実行するときに適切な環境を指定します。

$ tox -e py27

前述した特定テストと Python バージョンのテストを実行するには、2つの方法を組み合わせてください。

$ tox -e py27 tests/test_cd.sh

既存のファイルを変更して新しいテストを追加するか、 tests ディレクトリに新しいスクリプトを作成してください。

新しいテンプレートの作成

virtualenvwrapper.project テンプレートは virtualenvwrapper plugins と同じように動作します。 entry point グループの名前は virtualenvwrapper.project.template です。 run を実行する関数を参照する独自のエントリーポイントを設定してください (ソースフックはテンプレートをサポートしていません) 。

テンプレート関数の引数は、作成するプロジェクトの名前です。 カレントワークディレクトリは、プロジェクトのファイルを保持するために作成されたディレクトリです ($PROJECT_HOME/$envname) 。

ヘルプテキスト

プロジェクトテンプレートとその他の virtualenvwrapper 拡張との違いは、ユーザーが指定したテンプレートのみが実行されることです。 mkproject コマンドは、ユーザーへ利用できるテンプレート一覧表示するヘルプオプションがあります。 テンプレート名は、登録されたエントリーポイントから取得される名前です。 そして、テンプレートの説明は、テンプレート関数の docstrings を表示します。

既存の拡張機能

次に virtualenvwrapper で利用できる拡張機能を紹介します。

emacs-desktop

emacs desktop-mode はセッション間で emacs の状態(バッファのオープン、リングの削除、バッファの位置等)を保存させます。それは他の IDE に対する1つのプロジェクトファイルとして使用することもできます。 emacs-desktop プラグインは、カレントのデスクトップファイルを保存するトリガーを追加して、 workon で新しい仮想環境をアクティブ化するときに新たなファイルを読み込みます。

user_scripts

user_scripts 拡張は virtualenvwrapper で提供され、デフォルトで有効です。それは ユーザカスタマイズ で説明したユーザのカスタマイズスクリプト機能を実装します。

vim-virtualenv

vim-virtualenv は、Jeremey Cantrell によるプラグインで vim から virtualenvs を制御します。virtualenvwrapper と一緒に使う場合は、vim-virtualenv が編集するファイル名に対応してアクティブ化する virtualenv を識別します。

テンプレート

mkproject で利用できるテンプレートの一覧を紹介します。

bitbucket

bitbucket 拡張は、指定した bitbucket プロジェクトから自動的に mercurial のリポジトリをクローンします。

django

django 拡張は、自動的に新しい Django プロジェクトを作成します。

リリース履歴

dev

  • Clean up file permissions and remove shebangs from scripts not intended to be executed on the command line. (contributed by ralphbean)
  • Worked on some brittle tests.

3.2

  • Make project_dir a local variable so that cdproject does not interfere with other variables the user might have set. (contributed by slackorama)
  • Fix typo in documentation reported by Nick Martin.
  • Change trove classifier for license “MIT” to reflect the license text presented in the documentation. This does not indicate a change in the license, just a correction to the expression of that intent. See :ref:`license` (contributed by ralphbean as fix for issue 134)
  • Extend rmvirtualenv to allow removing more than one environment at a time. (contributed by ciberglo)
  • Change the definition of virtualenvwrapper_get_site_packages_dir to ask distutils for the site-packages directory instead of trying to build the path ourselves in the shell script. This should resolve issue 112 and improve support for Python interpreters other than C Python. Thanks to Carl Meyer and Dario Bertini for their contributions toward the fix.

3.1

  • Fix a problem with activation hooks when associating a new virtualenv with an existing project directory. (issue 122)
  • Fix a problem with command-add2virtualenv and paths containing “special” characters such as &. (issue 132)

3.0.1

  • Fix some packaging issues that made it more difficult to run the tests directly from the sdist package. (issue 126)

3.0

  • Add Python 3 support, thanks in large part to the efforts of Daniel Kraus (dakra). Tested under Python 2.6, 2.7, and 3.2.

2.11.1

  • Remove the initialization shortcut because it breaks tab completion in sub-shell environments like screen and tmux. (issue 121)

2.11

  • Add -a option to mkvirtualenv to associate a new virtualenv with an existing project directory. Contributed by Mike Fogel (mfogel).
  • Drops support for Python 2.4 and 2.5. The tools may still work, but I no longer have a development environment set up for testing them, so I do not officially support them.
  • Shortcut initialization if it has run before.
  • Set hook log file permissions to be group-writable. (issue 62 reported by hedgeddown)
  • Add VIRTUALENVWRAPPER_PROJECT_FILENAME variable so the .project file used to link a virtualenv to a project can be renamed to avoid conflicts with other tools. (issue 120 reported by arthuralvim)

2.10.1

2.10

  • Incorporated patch to add -d option to command-add2virtualenv, contributed by miracle2k.
  • Add -i option to mkvirtualenv.
  • Add mktmpenv command for creating temporary environments that are automatically removed when they are deactivated.
  • Fixed a problem with hook_loader that prevented it from working under Python 2.5 and 2.4.
  • Fix a problem with the way template names were processed under zsh. (issue 111)

2.9

  • Change the shell function shell definition syntax so that ksh will treat typeset-declared variables as local. No kidding.
  • Merge the “project directory” features of the virtualenvwrapper.project plugin into the main project, adding mkproject, cdproject, and setvirtualenvproject commands.
  • Add -r option to mkvirtualenv to install dependencies using a pip requirements file.

2.8

  • Use VIRTUALENVWRAPPER_VIRTUALENV in cpvirtualenv (issue 104).
  • Add support for MSYS environment under Windows. Contributed by Axel H. (noirbizarre).

2.7.2

  • Move setup code for tab completion later in the startup code so all of the needed variables are configured. (issue 97)
  • Expand tab completion for zsh to work for all commands.

2.7.1

  • When testing for WORKON_HOME during startup, dereference any symlink to make sure it is a directory.
  • Set VIRTUALENVWRAPPER_HOOK_DIR and VIRTUALENV_WRAPPER_LOG DIR in virtualenvwrapper_initialize after WORKON_HOME is set (issue 94).
  • Update the 基本的なインストール instructions to be more explicit about needing to install virtualenvwrapper globally (or at least outside of a virtualenv).

2.7

  • Fix problem with space in WORKON_HOME path (issue 79).
  • Fix problem with argument processing in lsvirtualenv under zsh (issue 86). Thanks to Nat Williams (natw) for the bug report and patch.
  • If WORKON_HOME does not exist, create it. Patch from Carl Karsten (CarlFK). Test updates based on patches from Matt Austin (maafy6) and Hugo Lopes Tavares (hltbra).
  • Merge in contributions from Paul McLanahan (pmclanahan) to fix the test harness to ensure that the test scripts are actually running under the expected shell.
  • Merge in new shell command toggleglobalsitepackages from Paul McLanahan (pmclanahan). The new command changes the configuration of the active virtualenv to enable or disable the global site-packages directory.
  • Fixed some tests that were failing under ksh on Ubuntu 10.10.
  • Document the VIRTUALENVWRAPPER_VIRTUALENV variable.
  • Implement suggestion by Van Lindberg to have VIRTUALENVWRAPPER_HOOK_DIR and VIRTUALENVWRAPPER_LOG_DIR variables to control the locations of hooks and logs.
  • Enabled tab completion for showvirtualenv (issue 78).
  • Fixed a problem with running rmvirtualenv from within the environment being removed (issue 83).
  • Removed use of -e option in calls to grep for better portability (issue 85).

2.6.3

  • http://readthedocs.org でドキュメントを生成するために setup.py や conf.py スクリプトのバージョン情報をハードコードしました。

2.6.2

2.6.1

  • virtualenvwrapper_get_python_version を修正しました(issue 73)。

2.6

  • Cygwin 環境でフックスクリプトの改行の問題を修正しました(issue 68)。
  • 互換シェルのリスト(サポートシェル) と Python バージョン(Python バージョン)を含むようにドキュメントを更新しました(issue 70)。
  • virtualenv のインストールの依存関係を修正しました(issue 60)。
  • Python 2.4 で動作するように Python バージョンを決定するメソッドを修正しました(issue 61)。
  • Makefile の自作スクリプトの代わりに tox を使用するためにテストインフラを変換しました。

2.5.3

  • doughellmann.com の休止期間中に PyPI へアップロードしたポイントリリースです。

2.5.2

  • zsh 環境の lsvirtualenv を修正する Zach Voase からのパッチを適用しました。 issue 64 を解決しました。

2.5.1

  • 数無しで実行したときに command-workon に完全な環境詳細ではなく簡潔な詳細を表示するようにしました。

2.5

  • showvirtualenv コマンドを追加しました。デフォルトで冗長な出力を行うように lsvirtualenv を変更しました。

2.4

  • command-workon が引数無しで実行されるときに get_env_details フックを実行するために -l オプションを持つ lsvirtualenv コマンドを追加しました。

2.3

  • get_env_details フックを追加しました。

2.2.2

  • エイリアスを避けてシェルコマンドをさらにエスケープ処理する Fred Palmer のパッチを取り込みました。 issue 57 を解決しました。
  • egrep 引数のエスケープ処理の問題を修正しました(issue 55)。
  • 引数無しで mkvirtualenv を実行するときの問題を修正しました(issue 56)。

2.2.1

  • which 呼び出しがエイリアスを避けるようにエスケープしました。 issue 46 を解決しました。
  • grep を呼び出す前に GREP_OPTIONS をアンセットする Manuel Kaufmann のパッチを取り込みました。 issue 51 を解決しました。
  • issue 53 を解決する正規表現の $ をエスケープしました。
  • rm のエイリアスに関する問題をエスケープして issue 50 を解決しました。

2.2

  • issue 43 を解決するために Python 2.4 で動作する形でフックローダの実行を切り替えました。
  • Python 2.7b1 でテストしました。 issue 44 を参照してください。
  • David Wolever からのパフォーマンス改善を取り込みました。 issue 38 を参照してください。
  • issue 35 のためにデバッグ命令を追加しました。

2.1.1

2.1

  • ksh サポートを追加しました。変更する箇所を調査してくれた Doug Latornell に感謝します。
  • 起動時に virtualenvwrapper.hook_loader のインポートテストをして、ユーザへ修正方法を理解するのに役立つようにエラーを報告します(issue 33)。
  • 新しい仮想環境が作成された後ですぐにアクティブ化することについて mkvirtualenv ドキュメントを更新しました(issue 30)。
  • cpvirtualenv に関連するフックを追加しました。
  • 特に ksh 環境で、非アクティブ化をより堅牢にしました。
  • 安全で移植性の高い一時ファイル名を作成するために Python の tempfile モジュールを使用しました。
  • 仮想環境がまだ1つも作成されていないときに仮想環境の名前として * を表示することで発生する virtualenvwrapper_show_workon_options の問題を修正しました。
  • 名前付きフックのみを実行できるようにフックローダを変更しました。
  • virtualenvwrapper.project の mkproject のようにコマンドのヘルプ出力を使用して利用可能なフックの取得サポートを追加しました。
  • mkvirtualenv の -h オプションの振る舞いを修正しました。
  • $WORKON_HOME/hook.log ファイルを 10KiB でローテートするように logging を変更しました。

2.0.2

  • virtualenvwrapper.user_scripts が Python 2.5 互換になるように issue 32 を修正しました。

2.0.1

  • TMPDIR がユーザのシェル環境でセットされていないときにデフォルト値を使用するように issue 29 を修正しました。

2.0

  • 拡張機能を共有し易くするために Distribute エントリポイントを使用してフック管理を書き直しました。

1.27

  • Added cpvirtualenv command [Thomas Desvenain]

1.26

  • Fix a problem with error messages showing up during init for users with the wrappers installed site-wide but who are not actually using them. See issue 26.
  • Split up the tests into multiple files.
  • Run all tests with all supported shells.

1.25

  • Merged in changes to cdsitepackages from William McVey. It now takes an argument and supports tab-completion for directories within site-packages.

1.24.2

  • Add user provided Tips とトリック section.
  • Add link to Rich Leland’s screencast to references section.

1.24.1

  • Add license text to the header of the script.

1.24

  • Resolve a bug with the preactivate hook not being run properly. Refer to issue 21 for complete details.

1.23

  • Resolve a bug with the postmkvirtualenv hook not being run properly. Refer to issue 19 and issue 20 for complete details.

1.22

  • Automatically create any missing hook scripts as stubs with comments to expose the feature in case users are not aware of it.

1.21

  • Better protection of $WORKON_HOME does not exist when the wrapper script is sourced.

1.20

  • Incorporate lssitepackages feature from Sander Smits.
  • Refactor some of the functions that were using copy-and-paste code to build path names.
  • Add a few tests.

1.19

  • Fix problem with add2virtualenv and relative paths. Thanks to Doug Latornell for the bug report James Bennett for the suggested fix.

1.18.1

  • Incorporate patch from Sascha Brossmann to fix a issue 15. Directory normalization was causing WORKON_HOME to appear to be a missing directory if there were control characters in the output of pwd.

1.18

  • Remove warning during installation if sphinxcontrib.paverutils is not installed. (issue 10)
  • Added some basic developer information to the documentation.
  • Added documentation for deactivate command.

1.17

  • Added documentation updates provided by Steve Steiner.

1.16

  • Merged in changes to cdvirtualenv from wam and added tests and docs.
  • Merged in changes to make error messages go to stderr, also provided by wam.
1.15
  • Better error handling in mkvirtualenv.
  • Remove bogus VIRTUALENV_WRAPPER_BIN variable.
1.14
  • Wrap the virtualenv version of deactivate() with one that lets us invoke the predeactivate hooks.
  • Fix virtualenvwrapper_show_workon_options for colorized versions of ls and write myself a note so I don’t break it again later.
  • Convert test.sh to use true tests with shunit2

1.13

  • Fix issue 5 by correctly handling symlinks and limiting the list of envs to things that look like they can be activated.

1.12

  • Check return value of virtualenvwrapper_verify_workon_home everywhere, thanks to Jeff Forcier for pointing out the errors.
  • Fix instructions at top of README, pointed out by Matthew Scott.
  • Add cdvirtualenv and cdsitepackages, contributed by James Bennett.
  • Enhance test.sh.

1.11

  • Optimize virtualenvwrapper_show_workon_options.
  • Add global postactivate hook.

1.10

1.9

  • Add more hooks for operations to run before and after creating or deleting environments based on changes from Chris Hasenpflug.

1.8.1

  • Corrected a problem with change to mkvirtualenv that lead to release 1.8 by using an alternate fix proposed by James in comments on release 1.4.

1.8

  • Fix for processing the argument list in mkvirtualenv from jorgevargas (issue 1)

1.7

  • Move to bitbucket.org for hosting
  • clean up TODO list and svn keywords
  • add license section below

1.6.1

  • More zsh support (fixes to rmvirtualenv) from Byron Clark.

1.6

  • Add completion support for zsh, courtesy of Ted Leung.

1.5

  • Fix some issues with spaces in directory or env names. They still don’t really work with virtualenv, though.
  • Added documentation for the postactivate and predeactivate scripts.

1.4

  • Includes a new .pth management function based on work contributed by James Bennett and Jannis Leidel.

1.3.x

  • Includes a fix for a nasty bug in rmvirtualenv identified by John Shimek.

参考文献

Ian Bicking の virtualenv が virtualenvwrapper の拡張機能を使用するために必須です。

さらに詳細は私が書いた2008年5月の Python マガジンのコラムを参照してください。 virtualenvwrapper | ところで話は変わりますが

Rich Leland は virtualenvwrapper の機能を誇示するために短い スクリーンキャスト を作成しました。

Manuel Kaufmann は このドキュメントをスペイン語に翻訳しました

Tetsuya Morimoto は このドキュメントを日本語に翻訳しました

サポート

問題や機能を議論するには virtualenvwrapper Google Group に参加してください。

BitBucket のバグトラッカー でバグを報告してください。

シェルエイリアス

virtualenvwrapper は大きなシェルスクリプトなので、多くのアクションはシェルコマンドを使用します。あなたの環境が多くのシェルエイリアスやその他のカスタマイズを行っているなら、何かしら問題に遭遇する可能性があります。バグトラッカーにバグを報告する前に、そういったエイリアスを無効な 状態 でテストしてください。あなたがその問題を引き起こすエイリアスを判別できるなら virtualenvwrapper をもっと堅牢なものにすることに役立つでしょう。

ライセンス

Copyright Doug Hellmann, All Rights Reserved

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Doug Hellmann not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.

DOUG HELLMANN DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL DOUG HELLMANN BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.