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

コードフォーマットが「uv」に実験的に導入される

2025年8月22日原文(pydevtools.com)

概要

uv 0.8.13 で新たに追加された uv format コマンドについて解説 Ruff のフォーマッターを利用した Pythonコード整形 機能 uv から直接フォーマット可能、他ツール不要 追加引数 で柔軟なカスタマイズ対応 実験的機能 のため、今後の変更や改善予定

uv format:Python開発者待望の新機能

  • uv 0.8.13 で実験的コマンド uv format が追加
  • Pythonコード のフォーマットをuvツールキットに統合
  • 複数のツールを使い分ける必要がなくなる利便性向上

uv formatの概要

  • uv format コマンドで Ruffのformatter を内部利用
  • 一貫性あるスタイルで自動的にコード整形
  • コマンド実行例:
    • プロジェクトルートでuv formatを実行
    • ruff format と同等の動作をuvインターフェイスで実現

導入手順

  • uv 0.8.13以降 を利用していることを確認
  • 必要に応じて uvアップグレード を推奨
  • コマンド一発で プロジェクト全体の整形 が可能

Ruffへの追加引数

  • --以降に Ruff用追加引数 を指定可能
    • 例:uv format -- --line-length 100
  • uvの利便性 を維持しつつ フォーマット動作を柔軟に調整

注意点と今後の展望

  • 実験的機能 のため、今後コマンド仕様が変更される可能性
  • uvのプロジェクトモデル との統合も進化予定
  • エラーハンドリングや出力形式 の改善余地あり
  • フィードバックが今後の機能進化に反映される可能性

開発ワークフローへの統合

  • uv format を活用することで Python開発効率化
  • 実験的段階 ゆえ積極的な試用とフィードバック推奨

Hackerたちの意見

これ、機能の肥大化って感じだね。去年からuvをどんどん使ってるけど(主にプロジェクトで使うから)、好きだし利点もわかるけど、まだ第一選択肢ではないんだよね。こんなことじゃ、ますます選ばれなくなると思う。

あなたの第一選択は何ですか?

このアプローチの何が具体的に悪いの?Goもこうやってるし、Rustもこうやってるし、Elixirもこうやってる。これによって、そういったエコシステムでのプロジェクトのセットアップや使用が大幅に楽になるんだよ。共通のツールセットのもとでコミュニティの努力が統一され、初心者も専門家もプロジェクトへの共通の入り口を持てるようになる。

uvを使うのはすごく楽しいけど、無駄に膨れ上がってるんじゃないかって不安になってきた。例えば、サブコマンドがサポートしてるニッチなフラグの数がめっちゃ多いし、同じ結果を得るフラグもあるみたい(uv run --no-project と uv run --active)。新しい(冗長な)機能を追加するより、既存のツールやドキュメントを改善してほしいな。

それはメインの実行ファイルに組み込まれてるの?それともaptやcargoみたいに別のバイナリなの?

Pythonプロジェクトを健全で再現可能、かつ合理的にポータブルな方法で進めるのは本当に難しい。uv syncは、再構築できることを約束できるパッケージセットだけを構築することができるけど、torch-tensorrtやflash-attnを一般的に構築することはできない。pipを実行したときに水星が逆行していたかどうかを知る方法がないからね。彼らは微妙で経済的に重要な針に糸を通そうとしている。Pythonコミュニティは「私のボックスで動く」の利益を独占し、コストを社会化することを重視している。ソフトウェアをデプロイ可能、セキュア、再現可能、信頼性のあるものにするためのコストは消えたわけじゃない!それはただ、後で別の場所で、自由度がはるかに少ない誰かの問題になっただけ。真剣に運用を考える人たちを満足させつつ、「私のボックスで動く...時々」な人たちを疎外しない方法でこれを実現するのは、神の仕事だね。

uvにサブコマンドを追加するのが無駄だって言われてる理由がわからない。uv自体はすでに複雑なツールだけど、ドキュメントはすごく優れてるし。こういうシンプルでわかりやすいサブコマンドを追加するのは、全然おかしくないと思うんだよね。

ruffの機能が最終的にuvやtyに統合されるのは驚かないな。リントはtyに向いてると思う。tyはコードベースをよく理解してるから、もっと賢いリントができるだろうし。フォーマットはuvに向いてると思う、プロジェクト管理がメインだからね。

tyはすでにruffと同じリポジトリにいるから、統合される可能性は高いね。

すでに素晴らしい時間テスト用のコードフォーマットツールがあるから、これには全く必要性を感じない。機能の肥大化って感じだし、今後のパイプラインには組み込まないつもり。

これが「時間が試された」選択肢のショートカットだってこと、分かってるよね?ruff formatはすでに広く使われてるから。

uv formatruff formatのフロントエンドに過ぎないよ。新しいフォーマッターをエコシステムに導入してるわけじゃないし。

Hacker Newsで議論の続きを見る