uv は先進ユーザーの間で普及しつつありますが、導入する明確な動機が見い出せていませんでした。Python + venv は Node.js + npm と似たような運用を可能にしますが、activate による状態遷移を伴う点が異なります。これが実は運用に大きく影響し、uv はそのギャップを埋めるものだと気付いたことが、導入のきっかけとなりました。それについてまとめます。
venv 運用の実態
大規模なプロジェクトではなく、個人的な運用での話です。
ディレクトリごとの venv 構築が面倒だったため、似たような用途のディレクトリで venv を使い回すことが常態化していました。その結果、個々の venv が何を目的として作られたのかが不明瞭になり、依存関係の管理も複雑化していきました。
具体的には、あるディレクトリで使用するパッケージには特定のバージョンを入れていたはずなのに、別のディレクトリで追加のパッケージを入れたために更新されてしまうなどの問題が発生しました。
作業環境の混乱も大きな課題でした。あちこちに作業ディレクトリが散在する中で、venv の activate 忘れによるエラーが発生しました。また、必ずしもディレクトリに包含関係があるわけではないことなどから、どの venv で実行していたか把握できなくなることもありました。
まさに散らかり放題の「汚部屋状態」といった状況でした。
【追記 2025/4/28】
ローリングリリース（バージョンに分けないで継続的に更新する方式）を採用する Arch Linux で python を更新したところ、あるタイミングで 3.12 から 3.13 への切り替えが発生しました。venv はバージョンごとにパッケージを分けるため、3.12 で使っていた venv が使えなくなりました。uv では python 本体のバージョンも含めて管理対象となるため、このような問題が回避できます。👉参考
activate 不要の持つ意味
MCP サーバー開発のため uv に触る機会がありました。
外部からスクリプトを実行する際、従来の venv のように activate する必要がなく、直接 uv 経由で実行できることに気付きました。
uv run /foo/bar/baz.py
python の代わりに uv run と打ち込むという感覚です。
これまでも venv と npm の類似性は認識していましたが、この activate 不要という特徴は、npm が以前から実現していたのとほぼ同じスタイルです。MCP サーバー開発では並行して TypeScript も使っていたため、そのことが明確に意識できました。
これまで当たり前のように行っていた activate という作業が実は負担になっていたことに気付くことで、uv のメリットが浮き彫りになったわけです。
uv による環境改善
uv を導入することで、より細かい粒度で環境の分離が可能になりました。その際、uv の高速性が大きく効いてくることも実感しました。従来の pip を使用していた場合、大規模なライブラリ群をインストールするのは時間がかかるため、結果として似たような用途のディレクトリ間で venv を使い回すことにつながっていました。それに対して uv ではインストール時間が大幅に短縮されることから、同じようなライブラリを複数回インストールすることへの実務的な障壁が大きく軽減されます。これは単なる待ち時間の短縮以上の意味があり、環境分離の実践をより現実的なものにしてくれます。
なお、ディレクトリごとに独立した環境を作ることによって、消費するディスク容量は増大します。共通のライブラリが環境ごとに重複するためです。しかし、最近のストレージ容量を考えれば、環境分離によるメリットが上回ると判断しました。
以上のように、uv によってディレクトリ単位での明確な分離が現実的になりました。また、あるディレクトリでどの venv を使うべきか考える必要もなくなりました。単にそのディレクトリで直接 uv コマンドを実行するだけで、適切な仮想環境が自動的に選択されるためです。
補足
ディレクトリ単位と書いていますが、その中にはサブディレクトリを含み、サブディレクトリは親ディレクトリの環境を共有する前提です。つまり用途ごとに分類して、その中で細分化します。
今まではナイーブに運用していたことから、必ずしも包含関係がないディレクトリでも venv を使い回すことがありました。そのようなケースに uv を導入する場合、pyproject.toml をコピーして uv sync で環境を作り直します。
pyproject.toml などの設定ファイルは、先入観で何だか面倒くさそうと思っていましたが、環境の再構築に有益だと気付いて見方が変わりました。
面倒に思っていたのは、あらかじめ手動で書く必要があると誤解していたことも一因です。実際は uv add したものが自動で追記されます。pip を使っていた時、後で環境を再構築するには何を pip install するのか列挙する必要がありましたが、それが自動で記録されるようなイメージです。
今後の展望
今後は既存の作業ディレクトリを段階的に uv での管理に移行していく予定です。
関連記事
参考
taskipy を使えば、make foo のように uv run task foo として実行するコマンドを登録できます。
以下の記事は npm との比較によって uv を捉えており、スタンスが似ています。