Python 仮想環境¶
Python 3.3 およびそれ以降のバージョンでは、 PEP 405 で "Python 仮想環境 <Python Virtual Environment>" の概念に対するサポートがインタープリタのレベルで導入されました。それぞれの仮想環境が独自の Python バイナリを持ち (従ってさまざまなバージョンの Python 環境を作成することが可能) 、そのサイトディレクトリの中にそれぞれ独立した Python パッケージ群をインストールすることができ、同時に、ベースシステムにインストールされた Python と標準ライブラリを共有することができます。仮想環境の概念はこのアップデートに先立って存在していましたが、(訳註、仮想環境を) 宣言したり発見したりするための標準化されたメカニズムはそれまで存在しなかったのです。
仮想環境のランタイムを識別する¶
ランタイムには、仮想環境は :py:data:sys.prefix (動作中のインタープリタのファイルシステム上の場所) が :py:data:sys.base_prefix (標準ライブラリのディレクトリのデフォルトでのファイルシステム上の場所) とは異なる値を持つおかげで識別可能です。
venv モジュールに関する Python 標準ライブラリの説明文書の How venvs work は、オペレーティングシステムの対話型シェル内で仮想環境を "活性化 <activating>" するという概念 (この活性化のステップはオプションであり、それがもたらす変化を使っても Python プログラムが仮想環境内で走っているのか否かを信頼できる形で判別することはできません) とともに、これを説明しています。
インストール先の環境がPython 仮想環境であることを宣言する¶
PEP 405 で述べられているように、最も単純な形式での Python 仮想環境は、 Python バイナリのコピーかシンボリックリンクに、 site-packages ディレクトリと、 Python 標準ライブラリのモジュール群がどこで見つかるかを指し示す home キーを伴った pyvenv.cfg ファイルが随伴しているだけのもので構成されます。
標準である venv モジュールの要求するものに合うように設計されている一方で、この分割実装と pyvenv.cfg ファイルのアプローチは、Python に特化したツール群が自身がすでに仮想環境の中で動作していて、それ以上の入れ子環境は要求もされておらず望ましくもないことを認識するようにしたいと望む Python 実装提供者なら 誰でも 採用することができます。
pyvenv.cfg ファイルがない場合であっても、 (例えばインストール済みの Python ランタイムにパッチを当てる sitecustomize.py のような) どんなアプローチでも、 :py:data:sys.prefix と :py:data:sys.base_prefix が相異なる値を持つような結果となる一方で、依然として対応するパッケージをインストールする枠組みを :py:mod:sysconfig 内で提供するアプローチであれば、それと認識されて Python 仮想環境として振る舞います。
歴史¶
2012年5月: PEP 405 を通じてこの仕様が承認されました。