Python 仮想環境

Python 3.3 およびそれ以降のバージョンでは、 PEP 405 で "Python 仮想環境 <Python Virtual Environment>" の概念に対するサポートがインタープリタのレベルで導入されました。それぞれの仮想環境が独自の Python バイナリを持ち (従ってさまざまなバージョンの Python 環境を作成することが可能) 、そのサイトディレクトリの中にそれぞれ独立した Python パッケージ群をインストールすることができ、同時に、ベースシステムにインストールされた Python と標準ライブラリを共有することができます。仮想環境の概念はこのアップデートに先立って存在していましたが、(訳註、仮想環境を) 宣言したり発見したりするための標準化されたメカニズムはそれまで存在しなかったのです。

仮想環境のランタイムを識別する

At runtime, virtual environments can be identified by virtue of sys.prefix (the filesystem location of the running interpreter) having a different value from sys.base_prefix (the default filesystem location of the standard library directories).

Python 標準ライブラリの venv モジュールに関する説明文書の How venvs work は、

インストール先の環境がPython 仮想環境であることを宣言する

PEP 405 で述べられているように、最も単純な形式での Python 仮想環境は、 Python バイナリのコピーかシンボリックリンクに、 site-packages ディレクトリと、 Python 標準ライブラリのモジュール群がどこで見つかるかを指し示す home キーを伴った pyvenv.cfg ファイルが随伴しているだけのもので構成されます。

標準である venv モジュールの要求するものに合うように設計されている一方で、この分割実装と pyvenv.cfg ファイルのアプローチは、Python に特化したツール群が自身がすでに仮想環境の中で動作していて、それ以上の入れ子環境は要求もされておらず望ましくもないことを認識するようにしたいと望む Python 実装提供者なら 誰でも 採用することができます。

pyvenv.cfg ファイルがない場合であっても、 sys.prefix と sys.base_prefix が相異なる値を持つような結果となる一方で以前として対応するパッケージ実装スキームを sysconfig 内で提供するアプローチ (例えば Python ランタイムにパッチを当てる sitecustomize.py) であればどれでも、それと認識されて Python 仮想環境として振る舞います。