virtualenvwrapper 3.5¶
virtualenvwrapper は Ian Bicking の virtualenv ツールの拡張機能です。この拡張機能は仮想環境の作成・削除を行ったり、開発ワークフローを管理するラッパーを提供します。このラッパーを使うことで、開発環境の依存関係による競合を起こさず、同時に複数のプロジェクトで作業しやすくなります。
機能¶
- 1つの場所に全ての仮想環境を構成する
- 仮想環境を管理(作成、削除、コピー)するラッパー
- 1つのコマンドで仮想環境を切り替える
- コマンドの引数から仮想環境をタブ補完できる
- 全ての操作をユーザ設定でフックできる(ユーザカスタマイズ を参照)
- 共有できる拡張機能を作成できるプラグインシステム(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
を実行する) 。
クイックスタート¶
workon
を実行する- 仮想環境のリストが表示されるか、何も表示されない
mkvirtualenv temp
を実行する- 新たな仮想環境
temp
が作成されてアクティブ化される workon
を実行する- このときに
temp
の仮想環境が提供される
設定¶
virtualenvwrapper は、環境変数を変更することでカスタマイズできます。 virtualenvwrapper.sh
が読み込まれる 前の シェルの起動ファイルで環境変数を設定してください。
仮想環境の場所¶
環境変数 WORKON_HOME
は、virtualenvwrapper が使う仮想環境の場所を指定します。デフォルト設定は $HOME/.virtualenvs
です。virtualenvwrapper が読み込まれたときにそのディレクトリが存在しない場合は、自動的に作成されます。
プロジェクトディレクトリの場所¶
環境変数 PROJECT_HOME
は、virtualenvwrapper が使うプロジェクトのワークディレクトリの場所を指定します。この環境変数は mkproject を利用する前に設定して、そのディレクトリを作成しておく必要があります。
See also
プロジェクトのリンクファイル名¶
環境変数 VIRTUALENVWRAPPER_PROJECT_FILENAME
は、virtualenvwrapper が使う、プロジェクトのワークディレクトリに対して virtualenv をリンクするファイル名を指定します。
See also
フックスクリプトの場所¶
環境変数 VIRTUALENVWRAPPER_HOOK_DIR
は、virtualenvwrapper が使う ユーザー定義のフック が保存される場所を指定します。デフォルト設定 $WORKON_HOME
です。
See also
フックログの場所¶
環境変数 VIRTUALENVWRAPPER_LOG_DIR
は、virtualenvwrapper のフックローダーが書き込むログの場所を指定します。デフォルト設定 $WORKON_HOME
です。
Python インタープリターと virtualenv と $PATH¶
起動ファイルの読み込み時に virtualenvwrapper.sh
は、最初に $PATH
上の python
と virtualenv
を見つけて、後で使うためにその情報を覚えておきます。これは 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_bashrc
を source /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
rmvirtualenv¶
WORKON_HOME の仮想環境を削除します。
構文:
rmvirtualenv ENVNAME
カレントの仮想環境を削除する前に deactivate を実行しなければなりません。
(mynewenv)$ deactivate
$ rmvirtualenv mynewenv
$ workon
$
See also
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
$
See also
仮想環境へ簡単に移動する¶
カレントのアクティブ化された仮想環境内へ移動するためのショートカットを提供する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_ENV
の site-packages
へカレントワークディレクトリを移動します。
構文:
cdsitepackages [subdir]
仮想環境の site-packages ディレクトリへの正確なパスは Python のバージョンに依存するので、 cdsitepackages
は cdvirtualenv 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 へ拡張ディレクトリを追加することも簡単です。
- Django のような、大きなプロジェクトのソースをチェックアウトする
add2virtualenv path_to_source
を実行するadd2virtualenv
を実行する- 使用方法とカレントの “拡張された” パスリストが表示される
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)$
プロジェクトディレクトリの管理¶
See also
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)$
See also
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 またはその他のテスト向けの依存関係をもったバージョン間で切り替えやすいように、同じプロジェクトディレクトリを参照できます。
virtualenvwrapper をカスタマイズする¶
virtualenvwrapper は仮想環境を作成・削除したり、環境間を移動したりするときに、設定内容、シェル環境またはその他の設定値を変更できる複数のフックポイントを追加します。そういったフック機能は2つの方法で提供されています。
ユーザカスタマイズ¶
エンドユーザのカスタマイズスクリプトは 読み込み (シェル環境を変更できる) されるか、適切な条件で外部プログラムのように 実行 されるかのどちらかです。
全ての環境に適用されるグローバルスクリプトは、 VIRTUALENVWRAPPER_HOOK_DIR で指定したディレクトリに置きます。ローカルスクリプトは virtualenv の bin
ディレクトリに置きます。
get_env_details¶
グローバル/ローカル: 両方 引数: 環境名 読み込み/実行: 実行
$VIRTUALENVWRAPPER_HOOK_DIR/get_env_details
は workon
が引数無しで実行されるときに実行されます。そして、仮想環境のリストを表示します。仮想環境の名前が表示された後で、そのフックは環境毎に一度実行されて、その環境に関する追加情報を表示します。
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_activate や post_activate フックを設定してください。 initialize は virtualenvwrapper に対するフックや完全に新しいコマンドを追加するためのフックです。そして pre_mkvirtualenv や post_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
という構文の文字列です。慣例からエントリポイントの 名前 はプラグインの名前を付けますが、必須だというわけではありません (その名前を使わなくても構いません) 。
See also
フックローダ¶
拡張機能は 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))
# ...
See also
拡張ポイント¶
ネイティブプラグインの拡張ポイントの名前は複数のパートを持つ命名規則 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_mkproject
と virtualenvwrapper.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 を使ってください。
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 Marr は git リポジトリ で動作するよく似た機能を書きました。
新しい環境に共通ツールを自動的にインストールする¶
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 要求ファイルを持ちます。
開発者向け¶
あなたが直接 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 のテストスイートは shunit2 と tox を使います。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 を識別します。
リリース履歴¶
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 askdistutils
for thesite-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
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
- Changed arguments to mktmpenv so it always creates an environment name for you. (issue 114 reported by alex_gaynor)
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
- http://readthedocs.org でドキュメントを生成してみました。
- Tetsuya Morimoto からの 日本語の翻訳ドキュメント を取り込みました。
- 環境変数 (VIRTUALENVWRAPPER_VIRTUALENV) で virtualenv バイナリをユーザが指定できるように Ales Zoulek からの提案を取り入れました。
2.6.1
- virtualenvwrapper_get_python_version を修正しました(issue 73)。
2.6
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
2.2.1
2.2
2.1.1
- Manuel Kaufmann の http://bitbucket.org/humitos/virtualenvwrapper-es-translation/ から スペイン語の翻訳ドキュメント を追加しました。
- ラッパーがインストールされる場所ではなく
$PATH
から Python の不適切な利用を修正しました。 issue 41 を参照してください。- zsh で仮想環境を非アクティブ化したときの誤ったエラー/ワーニングメッセージをなだめました。 issue 42 を参照してください。
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
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 ofpwd
.
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
- Pull in fix for colorized ls from Jeff Forcier (changeset b42a25f7b74a).
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.