パッケージ管理

Python を書き始めてしばらくすると、どこかで「仮想環境を作りましょう」という一文に出会う。入門書の多くは標準の venv を使う手順を載せていて、ここ数年の解説記事やプロジェクトの README には uv という名前もよく出てくる。どちらも「仮想環境を作る」ための道具として紹介されるので、最初のうちは何が違うのか分かりにくい。 私自身、両方を使い分けるようになってから気づいたのは、この二つは同じ仕事を奪い合っているのではなく、受け持つ範囲の広さが違うということだった。venv は「部品を入れる箱」を作るところまでを担当し、uv は箱を作ったうえで「何をどの版で入れたか」の記録や、Python 本体の用意まで引き受ける。この記事では、そもそも仮想環境が何を解決しているのかを確かめたうえで、venv と uv の作り方、記録の残し方、速さの理由を順に見ていき、最初の1本をどちらで作るかの目安を示したい。 仮想環境は、プロジェクトごとに部品の置き場を分ける仕組み エディターの下端には、そのファイルを動かしている Python の版が表示される。仮想環境を作ると、ここで選ぶ相手が増えるPhoto: MikeRun / CC BY-SA 4.0 Python で何かを作るときは、表計算のデータを扱う部品やグラフを描く部品のように、ほかの人が公開しているパッケージを取り込んで使うことが多い。これらは pip install で入れるのが基本だが、何も考えずに入れると、パソコンに入っている Python 本体の置き場にすべてが積み上がっていく。 困るのは、プロジェクトが二つ、三つと増えたときだ。古いプロジェクトでは部品の版1を前提に書いたのに、新しいプロジェクトのために版2へ上げた途端、古いほうが動かなくなる。版を戻せば今度は新しいほうが壊れる。どちらのプロジェクトがどの部品を必要としていたのかも、時間がたつと分からなくなる。 仮想環境は、この置き場をプロジェクトごとに分ける仕組みだ。プロジェクトのフォルダーの中に .venv という専用の置き場を作り、そこに Python の実行ファイルへの参照と、部品を入れる site-packages というフォルダーを用意する。その環境を使っているあいだは、pip install した部品が .venv の中だけに入り、ほかのプロジェクトには影響しない。不要になったら、.venv のフォルダーを丸ごと消せば元どおりになる。 要するに、仮想環境の本体はただのフォルダーで、特別な仮想マシンのようなものではない。この点を押さえておくと、venv と uv の違いも見通しやすくなる。 venvは標準の道具で、箱を作るところまでを担当する venv は Python 3.3 から標準で付いてくる仕組みで、追加で何かを入れなくても使える。作り方は、プロジェクトのフォルダーで次の1行を実行するだけだ。 python -m venv .venv これで .venv フォルダーができる。中には環境の設定を書いた pyvenv.cfg と、実行ファイルを置く場所(Windows では Scripts、macOS と Linux では bin)、部品を入れる site-packages が並ぶ。Python 3.4 以降は、作った時点で pip も環境の中に入っている。 ...