女性向けエンジニアスクール
3秒でわかる
プロジェクトごとにライブラリ置き場を分ける Python の仕組み。同じ端末で別バージョンを要求する案件を並行して進めても、互いを壊さずに済みます。
30秒図解
もう少し詳しく
どういうものか
Python の仮想環境は、そのプロジェクト専用のインタープリタとライブラリ置き場をフォルダとして 1 つ作る仕組みです。標準の venv モジュールで作れます。有効化すると、pip install の入れ先と python コマンドの参照先が、システム全体ではなくそのフォルダに切り替わります。
中身は魔法ではなく、bin (Windows では Scripts) と lib を持つただのフォルダです。壊れたら削除して作り直せます。
なぜ必要か
システムの Python に直接ライブラリを入れていくと、案件 A が pandas 1.5 を要求し、案件 B が 2.2 を要求した時点で行き詰まります。片方を入れると片方が動かなくなり、片方に合わせて上げると別のプロジェクトが壊れる、という循環に入ります。
もう 1 つの理由は再現性です。仮想環境に入れたものだけを一覧にすれば、そのプロジェクトが本当に必要としている依存関係が分かります。システム全体で作った一覧には無関係なものが大量に混ざり、他の人が同じ環境を作れません。
具体例
# 作る (プロジェクトのフォルダで実行)
python3 -m venv .venv
# 有効化 macOS / Linux
source .venv/bin/activate
# 有効化 Windows PowerShell
.venv\Scripts\Activate.ps1
# ここから先の pip は .venv の中だけに入る
pip install requests pandas
pip freeze > <a href="/glossary/requirements-txt" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">requirements.txt</a>
# 他の人が同じ環境を作るとき
pip install -r requirements.txt
deactivate有効化するとプロンプトの先頭に (.venv) が付きます。付いていなければ切り替わっていません。
つまずきやすいところ
作っただけで有効化を忘れる、というのが最も多い失敗です。ライブラリはシステム側に入り、後で「入れたはずなのに ModuleNotFoundError が出る」と悩むことになります。困ったときは which python (Windows では where python) で参照先を確かめます。
.venv フォルダを git に含めてしまう事故もよくあります。中身は自分の端末専用の実行ファイルなので、.gitignore に書いて除外し、共有するのは requirements.txt だけにします。
似た用語との違い
仮想環境が分けるのは Python のライブラリだけです。OS のパッケージや別言語の実行環境までは分けられません。そこまで揃えたい場合は Docker を使います。conda は仮想環境とパッケージ管理を兼ねた別系統の道具で、venv と混在させると解決が難しい不具合が起きます。
覚え方
「プロジェクト 1 つにつき道具箱 1 つ」。持ち運ぶのは箱ではなく、中身の一覧表です。
