ハクソク

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

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

2025年10月30日原文(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）もこれをサポートしています。

Hacker Newsで議論の続きを見る