ハクソク

世界を動かす技術を、日本語で。

Uvは、過去10年間でPythonエコシステムにとって最高の出来事です

208日前原文(emily.space)

概要

uv は、Python環境のインストールや管理、依存関係の同期を劇的に簡単にする 次世代ツール。 Astral 社が開発し、 Rust製 で圧倒的な高速性を誇る。 仮想環境管理、依存解決、Pythonバージョン固定 など、すべてを一括で高効率に実現。 uvx コマンドで、即座にツール利用や一時的な環境構築も可能。 Pythonエコシステムにおける 10年ぶりの革新 と呼べる存在。

uv：Pythonエコシステム最大の革新

  • uv は、Pythonの インストール・仮想環境管理・依存解決 を一手に担う新ツール
  • Astral 社製、 Ruff などで知られる開発チームによる信頼性
  • Rust で実装されており、従来ツールよりも 圧倒的な高速性 を実現
  • クロスプラットフォーム対応 （Linux、Mac、Windows）

uvの主な機能

  • 任意の Pythonバージョンの自動インストール
  • パッケージの高速導入 および依存関係の自動解決
  • 仮想環境の自動作成・管理
  • 依存関係の衝突解決 を迅速に実行（大規模プロジェクトに最適）

インストール方法

  • Linux/Mac：
    • curl -LsSf https://astral.sh/uv/install.sh | sh
  • Windows（PowerShell）：
    • powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
  • 既存のPython環境に影響を与えず、 安全に試用可能

プロジェクト管理と仮想環境

  • 仮想環境 の利用を推奨、uvは自動で仮想環境を構築
  • pyproject.toml を基に環境構築、依存関係やPythonバージョンを明示
  • pyproject.toml 例： 
    [project]
name = "my_project"
version = "1.0.0"
requires-python = ">=3.9,<3.13"
dependencies = [
  "astropy>=5.0.0",
  "pandas>=1.0.0,<2.0",
]
  • プロジェクト公開時も pyproject.toml が標準

新規プロジェクト作成

  • uv initで プロジェクト雛形 を自動生成
    • uv init --bare：pyproject.tomlのみ生成
    • uv init --package：Pythonパッケージ用雛形生成
    • uv init --helpで全オプション確認

既存プロジェクトでの利用

  • uv syncで 依存解決・仮想環境構築 を一括実行

    • Python本体・依存パッケージ を自動インストール
    • .venvディレクトリに仮想環境を作成
    • uv.lock で完全な依存バージョンを保存し、再現性を担保

  • 仮想環境のアクティベート不要

    • uv run <コマンド>で自動的に適切な仮想環境で実行
      • 例：uv run myscript.py、uv run jupyter lab

依存関係の追加・管理

  • pyproject.toml を手動編集可、uvが自動検出し環境を再構築
  • uv add numpy>=2.0で 依存関係を即時追加・バージョン指定も可能
  • リモート依存やローカルパッケージ にも対応（詳細は公式ドキュメント参照）

Pythonバージョンの固定

  • uv python pin 3.12.9で 特定バージョンに固定
    • チーム全体で 完全一致のPython環境 を再現可能

uvx：一時的なツール実行

  • uvx（uv toolの短縮）で 一時的な仮想環境＋ツール実行
    • 例：uvx ruffでRuffを即座に実行
    • キャッシュ利用 で2回目以降は超高速
  • 追加依存を指定して即座に起動
    • 例：uvx --with pandas,pyarrow ipythonでpandas付きIPythonを即起動
    • uvx jupyter labでJupyter Labを一時環境で起動
  • 用途例 ：一時的なデータ調査、コードリント、ノートブック閲覧など

導入事例と開発現場での価値

  • The Astrosky Ecosystem 開発での実体験
    • 複数OS・複数開発者・非同期作業でも 環境統一が容易
    • GitHub Actions でのCI/CDや本番サーバーでもuvを活用
    • 実験的依存や頻繁なバージョン変更 にも柔軟対応
    • 一貫性と信頼性 を高める基盤として機能

まとめ：uvがPythonエコシステムを変える理由

  • インストール・依存管理・仮想環境の一元化 による圧倒的な効率化
  • 超高速・高信頼性 で開発体験を刷新
  • 学習コストが低く、既存環境を壊さない安全性
  • uvx による柔軟なツール利用で、初心者から上級者まで幅広く支持

さらに知りたい方へ

  • uv公式ドキュメント で詳細なガイド・コマンドリファレンス・概念解説を提供
  • Getting Startedページ や実践的な使い方も充実

Hackerたちの意見

一般的にプロダクション環境でPythonを使うのはあまり好きじゃないけど（バッシュが提供する以上の機能が必要な一回限りのスクリプトやcronジョブには最高だと思う）、この意見には同意だね。最近、uvを使ってPythonを書いたけど、すごく快適でいろんなLSPともうまく統合されてたよ。

UVよりもタイプアノテーションとGILの削除を優先するね。UVはまだ若いし、成長痛を感じたこともある。すごく良いけど、スライスしたパンと同じレベルには置かないよ。ただのたくさんあるパッケージマネージャーの一つだし。

└

エコシステムへの影響については、uvはかなり上位にいると思う。言語自体については君の言う通りだね。GILなしのPythonの実際のユースケースに出会ったことある？まだないんだ。恩恵を受けるはずのものは、すでに高度に最適化されたネイティブモジュールで書かれてるみたいだし。

└

タイプアノテーションは2008年に導入されて、タイプヒントは2015年の9月に登場したんだよね。

└

GILの削除はどうなったの？

└

そういえば、私の経験では、みんながuvを褒める理由の多くは、pip（とvenv）が今できることを、昔はできなかったからだと思う。これは、いくつかのエコシステムの標準（多くのPEPで定義されている）や、それらの標準の認知度と採用が高まったから可能になったんだ。「pipを使って複雑な非Python依存関係を持つものをインストールする」話は、数年前よりずっと良くなった。2020年にpipが新しいリゾルバーを得たおかげもあるし、欲しいパッケージがプリビルドのホイールを提供している可能性が高くなったからでもある。10年前は、純粋なPythonプロジェクトでもソースパッケージに悩まされることが多くて、pipはまずローカルでホイールをビルドしなきゃいけなかった（https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-...）。もう一つの重要な変化は、PyPIのホイールに対してインストーラーが別々の.metadataファイルを取得できるようになったこと。これで、特定のプロジェクトの特定のバージョンに対する遷移的依存関係を、全ホイールをダウンロードしてMETADATAファイルを展開する必要なく、小さなプレーンテキストファイルから学べるようになった。（これはPKG-INFOを含むソース配布にも可能だけど、必ずそうしなきゃいけないわけじゃないし、ソース配布のメタデータにはホイールがビルドされるまで知られていない「動的」な依存関係が許可されているから、最悪の場合は特別なメタデータ専用のビルドフックを実行しなきゃいけない（ビルドシステムがサポートするために追加の努力が必要で、開発者が実装しなきゃいけない））。

└

役に立つ型アノテーション。今はちょっと無意味だよね。確かにドキュメントには役立つけど、修正するときに手間がかかるし痛い思いをする（まあ、半端なエージェントコーディングなら、あんまり問題じゃないかも）。もっと良いのは、ダックタイピングの代わりに事前に宣言された厳密モードがあればいいな。そうすれば、いろんなことが速くなると思う（その代わり、全てが壊れたり言語の精神が損なわれたりするけど）。UVの魅力がまだわからないけど、これは多分、私が年を取ってて、pyenvやvenvを何年も使ってきたからだと思う。新しいものは私の存在への攻撃みたいに感じる。でも、condaが消えてくれるなら、UVに移行する準備はできてるよ。

単一ファイルのPythonスクリプトについては、99%がそうなんだけど、スクリプトの最初にこれを入れるだけで生活がめちゃくちゃ楽になるよ： #!/usr/bin/env -S uv run --script

/// script

requires-python = ">=3.11"

dependencies = [ "modules", "here" ]

///

これでスクリプトはスタンドアロンの実行ファイルみたいに動いて、uvが指定されたモジュールを魔法のようにインストールして使ってくれる。

└

セキュリティの観点から見ると、こういうのはちょっとゾッとするね。スクリプトをコントロールして依存関係を指定しているならまだしも、他の使い方だと、スクリプトの作者が隠れたバグや悪意のある意図を持ったPythonの依存関係をインストールしないと信じるしかない。これはUVに対する批判ではなく、動的な依存関係の解決に対する批判だよ。UVが特定の依存関係やそのバージョンをホワイトリストにする方法を持っていたら、もっと安心できるんだけどね。

└

UVは指定されたモジュールを魔法のようにインストールして使うよ。インターネットにアクセスできて、使っているリポジトリがオンラインなら、毎回異なるバージョンのPythonが使われるかもしれないし、…

└

‘env’に‘-S’オプションが必要なのはなぜ？マニュアルページを見ても、ここでは何も役に立ってないように見えるし、実際に役に立ってないよ。

└

あなたの/usr/bin/envが-Sをサポートしていれば、はい。PyPAの用語で言うと、ディストリビューションパッケージをインストールして使います。「モジュール」という用語は、一般的にはインポートパッケージのコンポーネントを指します。つまり、ここに書く名前はuv pip installコマンドで使う名前で、コード内でimportする名前とは一致しないかもしれませんが、同じである必要があります。これはエコシステムの標準です（https://peps.python.org/pep-0723/）し、pipx（https://pipx.pypa.io）もこれをサポートしています。

俺は少数派かもしれないけど、uvはあまり好きじゃないな。

  1. やりたいことが多すぎる。お願いだから一つのことをしっかりやってほしい。pip、pyenv、virtualenv、ruffを一つのコマンドで置き換えようとしてるのが同時にやってる。
  2. 結局uv pipを使わなきゃいけないから、pipの完全な代替にはなってない。
  3. Dockerとうまく連携しない。
  4. もっと複雑さが増す。新しい環境変数（UV_TOOL_BIN_DIR、UV_SYSTEM_PYTHON、UV_LINK_MODEなど）を理解しなきゃいけなくなる。
└

uvのpipインターフェースは、バスタブに足をちょっと浸けるような感じだね。ちょっと時間を取って、フルマネージドインターフェースを試してみて： https://docs.astral.sh/uv/concepts/projects/dependencies その後のコマンドはこうなるよ：

  • uv add
  • uv sync
  • uv run すごく使いやすくて、あまり考えなくてもいいし、めちゃくちゃ速いよ。
└

Dockerと一緒に使うときにどんな問題に直面するの？

└

君の言いたいことは、pyenv、virtualenv、pipは3つの異なるツールであるべきだってことだよね。でも、普通の開発者にとっては、これらのツールはPythonの環境やバージョンを管理するために関連しているから、ひとつのことに思えるんだ。他の言語では、こういうのに3つの異なるツールはないし。pipとvirtualenvは複雑さを増すだけで、壊れると（結構よくあることだけど）デバッグがさらに難しくなるんだよね。「バトルテスト済み」ツールなのに。

└
  1. やりすぎなんだよね。お願いだから一つのことをちゃんとやってほしい。pip、pyenv、virtualenv、ruffを一つのコマンドで置き換えようとしてる。私の経験では、だいたいどれも上手くやってるけど。UVの置き換えで問題に直面してるの？ > 2. 結局uv pipを使う必要が出てくるから、pipの完全な置き換えにはなってないよね。uv pipは何に使う必要があるの？
└
  1. 結局、uv pipを使う必要があるから、pipの完全な代替にはならないんだよね。pipやvirtualenvを使わなきゃいけないってことに気づいて、uvは自分が探してたものじゃないって思った。もしvirtualenvを管理してpipを呼び出さなきゃならないなら、直接この二つを使うことにするよ。誰かが、他の言語にあるような、依存関係リストやバージョン要件（言語自体のものも含む）がマニフェストファイル（go.mod、package.jsonなど）に書かれていて、すべてがそのディレクトリ内で完結する非virtualenvのパッケージ管理ソリューションを紹介してくれることを期待してたんだけどね。
└

どういう意味でdockerとうまくいかないの？

└

やりたいことが多すぎる。お願いだから一つのことをやって、それをうまくやってほしい。 この原則には同意できないな。時には、キットセットが必要なこともあるんだ。買い物に行ったり、いくつものドキュメントを見たりしたくない。全部お任せしたいんだ。uvを使ってないから、パーツがうまく組み合うかは分からないけど、キットセットもいいし、アラカルトもいいよね。

└
  1. やりたいことが多すぎるよ。お願いだから、一つのことをちゃんとやってほしい。pip、pyenv、virtualenv、ruffを一つのコマンドで置き換えようとしてるけど、実際にはpip、pyenv、virtualenvを一緒に使うケースの方が多いと思う。三つの機能を一つにまとめるのは理にかなってるけど、uvはruffを置き換えるわけじゃない。
  2. 結局、uv pipを使うことになるから、pipの完全な置き換えにはなってないよ。uv pipは互換性のためにあって、移行を楽にするためなんだけど、uvのワークフローに完全に移行したら、ほとんどuv pipは使わないと思う。
  3. Dockerとの相性が悪い。どういう意味で？
  4. 複雑さが増すだけだよ。新しい環境変数、UV_TOOL_BIN_DIR、UV_SYSTEM_PYTHON、UV_LINK_MODEとかを理解しなきゃいけなくなる。触れる必要なんて全然ないのに。
└

やりたいことが多すぎるよ。お願いだから、一つのことをちゃんとやってほしい。pip、pyenv、virtualenv、ruffを一つのコマンドで置き換えようとしてるけど、uvはruffを置き換えようとはしてない。 結局、uv pipを使うことになるから、pipの完全な置き換えにはなってないよ。uv pipはpipを使わず、uv用の低レベルなpip互換インターフェースを提供してるから、実際にはuvがpipを置き換えてることになる。インターフェースを使うときの速度や他の利点もあるしね。私もuv pipやuv venvを使ってツールに慣れようとしたけど、普通の高レベルインターフェース以外の低レベルインターフェースが必要になったことは一度もないよ。 Dockerとの相性が悪い。どういうこと？

└

うん、同意だよ。PyWorldがそういう方向に進んでるみたいだから、無理やり学ぼうとしてる。uvはpoetryほど嫌いじゃないけど、pyenvやpipを使ってて問題にぶつかったことはあんまりないかな。うーん、もしかしたら複雑なプロジェクトに取り組んでなかったからかも。

環境をアクティベートする代わりに「uv」をすべてのコマンドの前に付ける方が好きだっていうのに驚いてる。もちろん、環境をアクティベートするのも選択肢だけどね。Pythonのバージョンをすごく簡単に管理できるのもいい。すべてが「バッテリー内蔵」って感じで、プロジェクトにローカルな感じがする。まだ十分に使ってないから、年に2回の「Python環境デバッグの日」を避けられるかはわからないけど、新しいプロジェクトでは標準として採用するだけの期待は持ててるよ。

└

個人的には、コマンドの前にuvを付けるのが好きだな。そうすると状態を持たないから、どのターミナルで環境をソースしているのか覚えておく必要がないし、コマンドを他の人にコピー＆ペーストするときも、相手のターミナルの状態を気にしなくて済む。単純に動くからいいよね。

└

すべてに「uv」を前置きする方が好きだし、環境をアクティベートする代わりに。 バーチャル環境のbin/（WindowsならScripts/）のパスを前置きすることもできるよ。「環境をアクティベートする」ってのは、ほんとにいくつかの環境変数を操作するだけなんだ。一般的には、上記のディレクトリをパスに追加して、$VIRTUAL_ENVをvenvのルートに設定して、プロンプトを設定する（私のシステムでは$PS1を変更することを意味する）ことで、リマインダーとして機能するし、変更を元に戻すために必要なものをセットアップする（私のシステムでは「deactivate」関数を定義することを意味するけど、他の人はそれ用の明示的なスクリプトを持ってるかもしれない）。個人的にはvenvの自動検出や、プロジェクトルートに対して特定の場所に置く圧力が好きじゃないんだ。 > Pythonのバージョンを簡単に管理できるのもいいよね。なんでみんなこれをそんなに重視するのかはまだ理解できないけど、そういうもんだよね。 > 毎年恒例の「Python環境デバッグの日」 もしこれがシステムPythonを基にしたvenvを持っていて、システムPythonをアップグレードしたからなら、uvはそれについて何もできないよ。venvは移動したり、基盤のPythonを変更したりするために設計されてるわけじゃないからね。でも、uvを使えば環境を再作成するのがずっと早くなるし、たぶんそれが実用的な解決策になると思うよ。

└

これはPythonだけのコメントじゃないけど、ただ動けばいいんだよ。環境を維持するために常に手間がかかるなんておかしい。

└

uvを使ってプロジェクトのvenvを自動的にアクティブにするためにmiseを使ってるけど、プレフィックスは時々役立つよ。忘れたときに同期をトリガーしてくれるからね。

UVを使う前はRustに全然注目してなかったけど、UVを使い始めてからはパフォーマンスに敏感なコードの開発をかなりRustに切り替えたよ（Pythonとのインターフェース付きで）。こういう改善は本当に生活の質を大幅に向上させてくれる。私の希望は、condaが完全になくなること。MLクラスターを運営していて、数ギガバイトのcondaディレクトリがあって、環境に触れるだけで再現できない研究者がいるから、本当に困ってるんだ。

└

私の理解では、condaはまだ存在してるのは、uvがPythonに特化してる一方で、condaは他の言語で書かれたものを扱ってるからだと思う。uvが予想以上に普遍的にならない限り、condaは残るだろうね。

└

pixiに興味があるかもしれないよ。これはcondaに対するuvみたいなもので（Rustで書かれていて、PyPIパッケージのためにuvソルバーを再利用してる）。

└

マルチギガバイトのcondaディレクトリに対する良い解決策があればいいよね。私の経験では、環境YAMLで依存関係を固定すればcondaは再現性があるし… 確かにビルドは遅いけど、再現性はあるよ。

└

私はMLのプロとして働いていて、ここ7年間はcondaに触れてないよ。MLクラスターでは、たぶんコンテナ化されてるから、その必要もないんじゃない？

└

ML/AIのワークロードのために大規模な依存関係を再現可能に管理するのは、かなり深い話題だよ。興味があれば、こちらがオープンドメインでの作業の一部だよ。 https://docs.metaflow.org/scaling/dependencies https://outerbounds.com/blog/containerize-with-fast-bakery

これらのコメント、全部広告っぽいな。「uvはPythonよりいい！！」「8/10のプログラマーがuvを推奨してる」「前はひどいプログラマーだったけど、uvが人生を変えてくれた！！」「uvは速い！！！」

プロジェクトを始めるときに詩に飛び込むのがちょっと怖い気がする。もうエコシステムは完全にuvに移行したのかな？Pythonのメインエコシステムにどんな影響を与えてるんだろう？

Pythonのツールが全然問題ないって何年も聞かされて、仮想環境とpipを使えばいいって言われて、JSの方が悪いに違いないって思ってたけど、Pythonの開発者たちがついにnpmやcargo、bundlerを体験したら、めっちゃ好きになってるのが面白い。確かにnpmには問題もあるけど、ロックファイルと一貫したインストールは素晴らしいよね。

uvの一番いいところは、condaじゃないところだね。pipもcondaじゃないけど、uvはpipよりずっと速いよ。