uvはこの10年でPythonエコシステムにもたらされた最大級の革新

 (emily.space)
29 ポイント 投稿者 GN⁺ 2025-10-30 | 7件のコメント | WhatsAppで共有
  • Pythonのインストールと仮想環境管理を画期的に簡素化したuvは、Pythonエコシステムにおける複雑な環境設定の問題を解決する
  • Rustで書かれており、速度と安定性を兼ね備え、Pythonバージョンのインストール・パッケージ管理・依存関係の解決を1つのコマンドで処理する
  • pyproject.tomlを自動認識してプロジェクト環境を構成し、uv syncによってチーム間で完全に同一の開発環境を再現できる
  • uv run、uv add、uvxなどのコマンドにより、仮想環境を有効化しなくても実行でき、パッケージ追加やワンショット実行も可能
  • Pythonのインストールと実行の一貫性を確保することで、uvは開発者の生産性と協業効率を大きく高める転換点と評価されている

uv概要

  • uvはAstralが開発した無料のオープンソースPython管理ツールで、複雑な環境設定プロセスを簡素化することを目指している
    • AstralはRuffのようなPython開発ツールを作っているチーム
    • uvはPythonバージョンのインストール、パッケージインストール、仮想環境管理、依存関係の解決をサポートし、速度面で既存ツールよりはるかに高速
  • Rustで開発されており性能が非常に高く、macOS、Linux、Windowsなどほぼすべてのプラットフォームで動作する

インストールと基本的な使い方

  • インストールは非常に簡単で、curlまたはPowerShellコマンド1行で実行できる
  • 既存のPythonインストールを変更しないため、安全に試せる
広告

プロジェクト環境管理

  • uvはPythonプロジェクトごとに仮想環境を自動管理し、pyproject.tomlファイルを認識して環境を設定する
    • pyproject.tomlにはPythonバージョン、依存関係リスト、プロジェクト名とバージョンなどを定義する
    • 例: 
      [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"]
    • この方式はpipよりも明確で標準化された環境定義を提供する

新しいプロジェクトの作成

  • uv initコマンドで新しいプロジェクトを簡単に作成できる
    • 自動的にpyproject.toml、README.mdなどの必須ファイルを作成する
    • --bare、--packageなどのオプションでさまざまな初期化形式をサポート
    • uv init --helpで詳細オプションを確認できる
広告

既存プロジェクトの同期

  • プロジェクトにpyproject.tomlがあれば、uv syncコマンドですぐに利用できる
    • 自動的にPythonバージョンをインストール
    • .venvディレクトリに仮想環境を作成
    • すべてのパッケージの**正確なバージョン情報を記録したuv.lock**を生成
  • uv runコマンドを使えば、環境を有効化しなくてもPythonスクリプトを実行できる
    • 例: uv run myscript.py, uv run jupyter lab

依存関係とPythonバージョン管理

  • uv add numpy>=2.0コマンドで依存関係を自動追加・管理できる
    • pyproject.tomlを直接修正する必要はない
  • uv python pin 3.12.9コマンドで特定のPythonバージョンを固定でき、環境の再現性が保証される
広告

uvx: 高速なワンショット実行

  • uvxは、別途環境設定をしなくてもツールをすぐに実行できるコマンド
    • 例: uvx ruff, uvx jupyter lab, uvx --with pandas,pyarrow ipython
    • キャッシュベースで非常に高速に再実行でき、実験的な作業に有用
  • そのため開発者は、仮想環境に縛られず一時的な実行環境を手軽に構成できる

もしこれでまだ納得できないなら: 個人的なメモ

  • The Astrosky Ecosystemの開発中、複数のOSでPython環境を統一するためにuvを導入した
    • すべての開発者とサーバーが完全に同一のPythonインストールと依存関係バージョンを使えるよう支援した
    • GitHub Actionsと本番サーバー環境でもuvがPython環境を管理している
  • uvのおかげでインストールとテスト環境の不一致問題がなくなり、開発者間の協業が単純化された

結論

  • uvはPythonのインストール・管理における複雑さを根本から解消し、開発者が同一環境で安定して協業できるようにする
  • 高速さとRustベースの安定性により、uvは「この10年でPythonエコシステムに起きた最大の革新」と評価されている

関連記事

7件のコメント

 
kkksss 2025-11-06

pdm は uv とほとんど同じようなものだと思っていましたが、pdm に関する話はあまり出てこないですね
 
yuntae 2025-10-30

uv関連の投稿は、もう内容があまり大きく変わらない気がします
 
pmc7777 2025-10-30

MavenとGradleも..
 
GN⁺ 2025-10-30
Hacker Newsの意見

  • 以前はPythonのツール群で十分だと言われていたが、いまPython開発者たちがnpmやcargo、bundlerのようなlockfileベースのエコシステムを経験して、その利点に気づいているのを見ると胸がすく
    npmにも問題はあるが、一貫したインストールとロックファイルは本当に優れた概念だ

    • 他人のPythonプロジェクトを動かさなければならない時ほど怖いものはない
      これほど長い間、環境管理が不便だったことに驚く
    • なぜこんなに時間がかかったのか気になる
      数多くの試みが失敗した理由が、単にパッケージ管理の難しさだったのか、それともVC資金が必要だったのか疑問だ
    • 昔からpip freeze > requirements.txtとpip install -r requirements.txtを使ってきた
      バージョン範囲を書かなければ、実質的にrequirements.txtがlockfileの役割を果たす
      だから最近の「公式lockfile」ブームは少し誇張されている気がする
    • npmにもしばらくlockfileはなかった
      yarnの登場によってnpmが改善された部分は大きいと思う
    • 1998年からWeb開発をしてきたが、npmよりPNPMのほうがはるかに優れていると思う
      より速く、効率的で、決定的だ
      詳しくは pnpm.io/motivation を参照

  • UVスクリプトを使ってMCPクライアント/サーバーを単一ファイルで配布できた
    関連記事: MCP server in a file

  • ほとんどのスクリプトは単一ファイルなので、先頭に以下のコードを追加すると生活がずっとシンプルになる
    #!/usr/bin/env -S uv run --script
    こうするとスクリプトが独立実行ファイルのように動作し、uvが必要なモジュールを自動でインストールしてくれる

    • セキュリティの観点では、このやり方にはややリスク要因がある
      スクリプト作者が悪意ある依存関係を隠せるかもしれないからだ
      ホワイトリスト機能があるとよい
    • 現在日付ベースの最大リリース日フラグを使えば、lockfileなしでもバージョンを固定できる
      ただし一部パッケージではリリース日を検知できない（例: yaml）
    • 実行にはuvがインストールされている必要があるので、完全なstandaloneではない
    • /usr/bin/env -Sをサポートしている必要があり、依存関係名にはuv pip installコマンドで使う配布パッケージ名を書く必要がある
      これは PEP 723 標準で、pipx も対応している
    • インターネット接続が必要で、リポジトリの状態によっては異なるバージョンがインストールされる可能性もある

  • uvを使う前はRustに興味がなかったが、uvのおかげで性能に敏感なコードはRustへ移すようになった
    condaは完全に消えてほしい。MLクラスタではconda環境が大きくなりすぎ、再現性も低い

    • condaの代替として、Rust製のpixiを勧められた。uvのPyPIソルバーを再利用している
    • condaは依存関係を固定すれば再現性はあるが、ビルドが遅い
    • MLクラスタならコンテナ化されているはずで、condaは不要だと思う
    • uvでCUDA依存関係の管理をどうやるのか気になる
    • 大規模ML依存関係管理へのオープンソースなアプローチについては Metaflow docs と Fast Bakeryブログ を参照

  • 以前はpyenv + venv + pip + pipxの組み合わせで十分満足していたが、uvは

    • 依存関係解決の速度が非常に速く
    • uv run, uv add などで使い勝手が大幅に向上し
    • 複数のツールを1つに統合し
    • Pythonのインストールも簡単になった

  • 環境をactivateする代わりに、コマンドの前にuvを付けるほうがずっと楽だ
    Pythonバージョン管理も簡単になり、プロジェクトごとに全部入りの感覚がある
    長期的な安定性はまだわからないが、新規プロジェクトではデフォルトで使っている

    • 環境のactivateは、単にPATHとプロンプトを調整するだけだ
      uvが自動で環境を検出するのを嫌う人もいる
      Pythonバージョン管理の価値はあまりわからないが、uvだと環境の再作成はずっと速い
    • uvを付けるとstatelessにコマンドを実行でき、共同作業で便利だ
    • miseと一緒に使って自動activateしているが、uvプレフィックスは依然として有用だ
    • uvの哲学はvenvは使い捨てだということだ。問題が起きたら.venvを消せばいい
    • 実際のところ、こうした環境設定はただ「動いて当然」であるべき問題だ

  • このブログ記事は自分の経験とほぼ一致している
    摩擦が減ってシンプルになった
    Pythonコミュニティがuvを標準ツールとして採用してほしい

  • Rustベースのツールはフィードバック速度を完全に変えた
    ただ、Astralがどう収益化するのかは気になる。投資も受けているのに有料製品がない

    • Astralの収益モデルはオープンソースツールと統合されたエンタープライズソフトウェアの販売だ
      例: 社内向けパッケージレジストリ
      関連インタビュー: Charlie Marshインタビュー
    • 有料サービスへ発展する可能性がある製品は Pyx
    • Condaも「セキュリティ強化パッケージ」へのアクセスだけで収益を上げている
      Python開発者が1,000万人いるなら、uvも十分にマネタイズ可能だと思う

  • 個人的には型アノテーションとGIL削除のほうがuvより重要だと思う
    uvはまだ初期段階で不便さもある。結局はまた1つのパッケージマネージャーにすぎない

    • 人々がuvを称賛する理由の一部は、実際にはpipとvenvが標準化されたPEP群のおかげで改善された結果でもある
      pipの新しいresolverとwheel配布の増加が大きな役割を果たした
      関連記事: Wheels are faster for pure Python
    • 言語レベルではGIL削除のほうがより大きな変化だろうが、実際に有用なユースケースはまだ多くない
    • 型ヒントはすでに2015年に導入された古い機能だ
    • uvは単なるパッケージマネージャーではなく、配布の簡素化に大きな価値がある
      Rustで書かれているのも興味深い。LLVMのように他言語を支援する構造だ
      エンドユーザーの立場ではuvのほうがずっと良く、メンテナーにとって不便ならフィードバックすればよい
    • 型アノテーションはドキュメント化には良いが、実用性は低い
      厳格モードができれば性能向上も可能かもしれないが、言語哲学と衝突する
      それでもcondaが消えるならuvへ移るつもりだ

  • 私はuvが気に入らない

    • あまりに多くをやろうとしている: pip、pyenv、virtualenv、ruffまで一度に置き換えようとしている
    • uv pipを使わないといけないので、完全な置き換えでもない
    • Dockerとの互換性も低い
    • 新しい環境変数が多く、複雑さの増加がある
    • pyenv、virtualenv、pipが別々にあることは不自然だとは思わない
      ただしpipとvenvもよく壊れるし、デバッグはさらに難しい
    • 実際にはpip、pyenv、virtualenvは常に一緒に使われるので、統合ツールは合理的だ
      uvはruffを置き換えない
      環境変数はいじる必要もない
    • uv pipはpipを呼び出しているのではなく、互換インターフェースを提供している
      実際にはuvがpipを置き換えている
      Docker互換性の問題が具体的に何なのか気になる
    • uv add, uv sync, uv runで管理すると、ずっと人間工学的で高速だ
      詳細は uv dependencies concepts を参照
    • 私の経験ではuvは複数の役割をうまくこなしている。具体的にどんな問題に遭遇したのか気になる
 
aer0700 2025-11-01

uv が速いのは良いのですが、pip を改善する方向に進んでいたらどうだっただろう、と思ってしまいますね。
 
ztaka 2025-11-02

MLやWebで活用していますが、uvが早く当たり前の退屈な技術になることを期待しています（笑）
 
doolayer 2025-10-30

requirements しかなくて pyproject.toml のないリポジトリを見ると、もう時代遅れに見えますね（笑）;