Rust製の非常に高速なPythonパッケージおよびプロジェクトマネージャー uv

 (github.com/astral-sh)
4 ポイント 投稿者 GN⁺ 2025-06-24 | 1件のコメント | WhatsAppで共有
  • uvはRustベースの非常に高速なPythonパッケージおよびプロジェクト管理ツール
  • pip、pip-tools、pipx、poetry、pyenv、virtualenv などを1つに置き換え可能
  • 最大10〜100倍高速な性能とディスク容量の節約、強力なキャッシュ、cross-platformサポートを提供
  • スクリプト、プロジェクト、ツール、さまざまなPythonバージョン管理など、統合的な開発環境を支援する機能を含む
  • 開発生産性、大規模プロジェクト、高速な作業スピードに最適化されたモダンなPython開発ワークフローを実現可能

オープンソース紹介と差別化ポイント

  • uvは既存のpip、pip-tools、pipx、poetry、pyenv、virtualenv、twineなど、複数のPython管理ツールの機能を1つの単一ツールに統合
  • Rustで開発されており、非常に高い性能を持ち、従来のpipと比べて10〜100倍高速なインストールおよび同期速度を誇る
  • グローバルキャッシュと依存関係の重複排除により、ディスク使用の最適化機能を提供し、直感的なCLIと使い慣れたpip互換性をサポート
  • macOS、Linux、Windowsなど、さまざまなプラットフォームでスタンドアロン実行ファイルとしてインストール可能
  • スタンドアロンインストール方式、pipおよびpipxとの連携、独自の自動更新サポートなど、利便性強化が特徴

主な特徴(Highlights)

  • 1つのuvツールでpip、pip-tools、pipx、poetry、pyenv、twine、virtualenv などの多様な機能を置き換え可能
  • 既存のpipと比べて10〜100倍高速なインストール/更新/同期性能を提供
  • lockfileベースでプロジェクトの依存関係を管理し、workspaces、universal lockfileをサポート
  • スクリプト依存関係のインライン宣言および自動的な環境分離実行機能
  • さまざまなPythonバージョンの管理/インストール/切り替えをサポート
  • Pythonパッケージとして配布されたツールの実行およびインストールをサポート（pipxの代替）
  • pipインターフェース互換および追加機能を提供（バージョン上書き、プラットフォーム非依存の解決など）
  • Cargoスタイルのworkspaceで大規模プロジェクトに最適化
  • グローバルキャッシュで依存関係の重複を最小化し、ディスク容量を効率化
  • Rust/Python環境がなくてもcurl または pip、pipxでインストールおよび利用可能
  • macOS、Linux、Windows などマルチプラットフォーム対応
  • AstralおよびRuffを開発したチームが制作

プロジェクト管理(Project Management)

  • プロジェクト単位で依存関係、環境、ロック(lock)ファイル、workspaceなどを完全サポート
  • uv initコマンドでプロジェクトを自動初期化し、virtualenvを生成
  • uv addで依存関係を追加し、uv lockおよびuv syncコマンドでパッケージ同期とセキュリティ監査を自動処理
  • Poetry、Rye などのモダンなPythonプロジェクト管理ツールの機能を置き換えつつ、より高速な処理性能を保証
  • uvで管理していないプロジェクトのビルドおよび配布(publish)もサポート
広告

スクリプト管理(Scripts)

  • 単一ファイルスクリプトに依存関係のインラインメタデータを宣言可能
  • スクリプト実行時に自動で仮想環境を分離し、依存関係をインストール可能
  • uv add --scriptでスクリプトごとに依存関係を管理し、uv runコマンドで環境を分離して実行
  • データサイエンス/自動化のような単発スクリプトの活用に最適化

ツール管理(Tools)

  • Pythonパッケージ形式のCLIツールをpipxのようにインストールおよび実行可能
  • uv tool install、uvxコマンドで一時環境またはグローバル実行を活用
  • インストール済みツールの確認、バージョン管理、更新をサポート

Pythonバージョン管理

  • 複数のPythonバージョンを簡単にインストールし、即座に切り替え可能
  • さまざまなバージョンを並行管理し、プロジェクトごとに.python-versionのピン設定が可能
  • pypy などの代替実装も同一インターフェースでサポート
  • uv python install/pinなどのコマンドでバージョンのインストール、指定、有効化

pipインターフェース(Pip Interface)

  • uv pip、uv venvで既存のpip、pip-tools、virtualenvを完全に置き換え
  • 依存関係バージョンのoverride、プラットフォーム非依存の解決、再現可能なビルドなど高度な機能を含む
  • 既存ワークフローを変更せずにpipのdrop-in代替として利用でき、10〜100倍の性能向上を提供
  • requirements.in → requirements.txt 変換、仮想環境作成、およびrequirements同期をサポート

プラットフォームおよびバージョンポリシー

  • さまざまなOS(Windows、macOS、Linux)をサポート
  • ポリシーおよび対応プラットフォーム情報は公式ドキュメントを参照可能
広告

コントリビューション(Contributing)

  • 初心者から専門家まで、多様な貢献者を支援することを目標とし、関連ガイドを提供

FAQ

  • uvの発音は「ユー・ブイ」
  • スタイルは小文字の「uv」で固定

技術的背景および謝辞(Acknowledgements)

  • 依存関係解決アルゴリズムにはPubGrubを使用
  • Git実装はCargoベース
  • 最適化戦略はpnpm、Orogene、Bun、Posyなど最新のパッケージングツールから多くの着想を得ている

ライセンス

  • MIT および Apache-2.0のいずれかを選択して利用可能
  • コントリビュートされたコードも同条件でデュアルライセンスされる

関連記事

1件のコメント

 
GN⁺ 2025-06-24
Hacker Newsのコメント

  • 数か月前までは、uvは絶対に使わないと思っていた。すでに venv と pip に慣れていて、別のツールが必要だとは思っていなかったから。でも最近、共有サーバーで root 権限がない状況で各種パッケージやドライバがことごとく壊れていて、pytorch が必要になった経験をきっかけに、完全に uv へ移行した。pip は時間がかかるし、キャッシュが非常に容量を食ううえ、置き場所の変更もうまくできない不便さがあった。uv に切り替えたらすべてがとてもうまく動いて満足している。まだ迷っているなら、5分だけでもぜひ試してみてほしい

    • uv の最大の利点は、これまで使っていた venv ベースのワークフローと完全に互換性があること。単に uv venv を実行すれば済む
    • uv は説明するときや、特に初心者に使い方を案内するときに、ずっと分かりやすく感じる。pip + 設定ファイル + venv の組み合わせは、正しい venv を作ってインストールする手順や、スクリプト実行・テストのたびに不格好な shebang や venv の有効化を覚えておかなければならず混乱しやすかったし、エラーメッセージも十分に助けにならなかった。初心者に教える際、ツール群が本当に煩雑に感じられたが、今では「uv run」「uv add」「uv sync」だけ覚えればいいので、チームメンバーもずっと気軽に受け入れている雰囲気
    • 自分は asdf を使っていたが mise に移行したので、uv のような汎用ツールと比べるとどうなのか気になる
    • pip のキャッシュがかなり容量を食っていて、しかも置き場所もまともに変えられなかったとのことだが、uv はストレージ使用の面でより優れているのか気になる。もしそうなら、その理由が共有のうまさにあるのかも知りたい
    • 最近、実験用リポジトリで「uv a b c」から始まる簡単なガイドを見て実行してみた。内部的には重複が多いようにも見えるが、実運用では GNU-Debian-Ubuntu の標準的なホスト上で特に問題はなく、すべて順調に動いたので満足している

  • 初めて uv を使ったとき、pip と比べてあまりにも早く終わるので、何か失敗したかちゃんと動いていないのではないかと思ったのを覚えている

    • パッケージのインストールが 200ms くらいで終わることもあり、Enter 入力とプロンプト表示の間にほんのわずかな遅延を感じる程度。でも Poetry だとコーヒーを一杯飲んで戻ってくるころに終わるレベルなので、速度差は歴然としている
    • 自分もまったく同じ感覚だった。あまりにスムーズで、Python ではないような体験
    • 最近まさに同じ経験をして、そのおかげで完全に uv に乗り換えた立場
    • 自分も疑わしく思うほどだったが、試してからはもう元には戻れないくらい満足している

  • uv と ruff は、「絶対に車輪の再発明をするな」という言葉に対する見事な反例だと思う。目的が明確なら、既存よりはるかに優れたものができる場合もある

    • たいていその言葉が当てはまるのは、既存をよく知らない初心者への助言という文脈だと思う。つまり、システムの限界や改善点を分からない人が軽率に再発明を試みるときにだけ当てはまる。本当の専門家には当てはまらない
    • 彼らは車輪を再発明したのではなく、既存の木製の車輪をもっと頑丈な素材に置き換えて、10倍の速度で回せるようにした、という比喩
    • Python パッケージ管理の歴史を見るだけでも、誰もが既存よりうまく作ろうとして参入してくる印象がある
    • 実際、「車輪を再発明しない」ということわざ自体がおかしい。現実の車輪だって私たちは改良し続けてきたのだから、ソフトウェアでもより良い車輪を作らない理由はない
    • 少し話が逸れるが、なぜ "order of magnitude better" の代わりに短い "10x" と言わず、わざわざ長い表現を好むのか気になる

  • 小型・低スペック環境（AWS T2.micro 上の Windows など）では、uv が同時ダウンロードを多く試みすぎてタイムアウトする。環境変数 UV_CONCURRENT_DOWNLOADS で同時ダウンロード数を 1〜2 程度に制限すると解決する。uv のデフォルト設定はやや攻めすぎに感じるので、サーバーごとのスレッド自動調整にダウンロード速度を利用するような改善があるとよいと思う

    • まったく珍しいケースではなく、多くのユーザーが安価な VPS でサイドプロジェクトを動かしている（自分もよくそうする、AWS ではないけれど）。共有してくれてありがとう、自動検出機能が改善されるといいね

  • 最近ノートPCで uv を個人用に試しているが、pip に慣れていた立場からすると、体感速度がどうにも信じられないほど速くて、何度かちゃんと実行されたのか戸惑ったことがある

  • uv add <mydependencies> --script mycoolscript.py というコマンドが気に入っている。さらに先頭に #!/usr/bin/env -S uv run を付けると Python スクリプトを即実行できるので、とても便利なツールとして使っている

    • このやり方を Claude Project 向けの専用プロンプトで教えておくと、単一の入力だけで依存関係込みのスクリプト全体を自動生成することもできる。Claude 4 のカットオフは 2025年3月。Claude Sonnet 4 では追加プロンプトなしでもこの機能が動く。たとえば URL を入力すると、httpx と beautifulsoup でクロールしてリンク一覧を CSV で返すコードをその場で生成してくれる。関連資料 Claude スクリプト結果
    • Marimo.io ノートブックの app-mode と組み合わせてこのトリックを使っている。uv さえインストールされていれば、その場で反応的かつ再現可能なアプリを、ほとんど準備なしで他人に簡単に渡せる。本当に最高の組み合わせ
    • 今では小さなスクリプトも思いついたらすぐ実行する習慣がついた。環境や依存関係の管理を気にしなくてよくなり、ずっと快適になった。the little scripter 関連記事、関連YouTube動画、ez-mcp GitHub
    • 例を読み違えていたという訂正と、プロジェクト文脈では uv add --script と単なる uv add は異なるという説明。それに加えて、公式ドキュメントには run --with や PEP723 サポートなど、さらに便利な機能が多いので確認を勧める。公式ガイド
    • "mydependencies" とは具体的に何なのか、設定ファイルの意味なのかという質問

  • 以前 uv を試したことがあるが、圧倒的に速くて使いやすく、驚いた。今ではほぼ pip を使う理由がなく、Python だけ使うなら conda も不要になった

    • pyenv と poetry ももう使わなくなった

  • UV が本当に好き。Astral チームの Ruff も気に入っていて、従来の pylint + Black から、lint と format の両方を Ruff に移した。lint 時間が 90 秒から 1.5 秒未満に短縮されて驚いた

    • ただし、ruff は pylint の一部のチェックしか行わず、かなり明白なエラーも検出できずに通してしまうことを後で知って残念だった（実行不能なコードなども引っかからない）

  • 最近は、以下のパターンで小さな実行可能スクリプトを動かすのが新たに気に入っていて、よく使っている

    #!/usr/bin/env -S uv --quiet run --script
# /// script
# requires-python = ">=3.13"
# dependencies = [
#   "python-dateutil",
# ]
# ///
#
# [python script that needs dateutil]
    • shebang の行があまりにも覚えにくいので、単に #!/usr/bin/env uvx くらいの、もっと単純な形があるといい。使うたびに検索しなければならないのが面倒

  • 完全に満足していて、pip / twine / requirements.txt に戻りたいとは思わない。複数プロジェクトが社内 GitLab に共通ホイールを置いていたが、従来は YAML 10行分必要だったものを uv build と uv publish の2行で置き換えられる。依存関係の取り込みも楽だし、主要な依存関係も一度に確認できる。requirements.txt にすべてを混在させておく煩わしさがなくなる