Python 3.3 の組み込みの方法を使用して、virtualenv (venv) を作成してアクティブにします。
$ python3.3 -m venv env
$ source env/bin/activate
この時点pythonで、私の virtualenv の python は次のようになります。
(env) $ which python
/my_home_directory/env/bin/python
次に、distribute と pip をインストールしたいので、セットアップ スクリプトをダウンロードして実行します。
(env)$ wget http://python-distribute.org/distribute_setup.py
(env)$ wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py
(env)$ python distribute_setup.py
(env)$ python get-pip.py
これらのコマンドは正常に完了します。この時点で、venv を調べて、以前は存在しなかった「local」という名前の別のディレクトリを見つけました。env/local/bin には私の easy_install と pip の実行可能ファイルが含まれており、それらはまだ私のシステムの既存の easy_install と pip にエイリアスされています:
(env)$ ls env
bin include lib local pyvenv.cfg
(env)$ ls env/bin
activate pydoc python python3 python3.3
(env)$ ls env/local/bin
easy_install easy_install-3.3 pip pip-3.3
(env)$ which easy_install
/usr/bin/easy_install
(env)$ which pip
/usr/bin/pip
これは Python 2.x の振る舞いから逸脱していると思います。この時点で、私は virtualenv のコピーを使用することを期待easy_installしており、それらを使用して卵をインストールすると、virtualenv に配置されます。pip
さらに進んで、env/bin/activate を開いて、env/bin がシステム パスの先頭に追加されていることを確認しましたが、env/local/bin はそうではありません。それは私が見ている行動を説明しています。env/bin/activate を編集して env/local/bin ディレクトリをパスに追加することで、この問題を回避できます。
_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/bin:$PATH"
PATH="$VIRTUAL_ENV/local/bin:$PATH" # my new line
export PATH
それで、ここで何が起こっているのですか？これはバグですか、それとも何か不足していますか?
それが違いを生む場合に備えて、私はUbuntu 12.10を使用しています。