コードフォーマット機能が実験的にuvに導入

• 新しいuvバージョンで コードフォーマット 機能が実験的に提供される
• uv format コマンドは Ruffのフォーマッタ を内部的に使用してPythonコードを一貫したスタイルに整える
• 従来のように別個のツールを使わず、uvだけで手軽にコード整理作業 が可能
• ユーザーは追加引数を通じて フォーマット動作を細かく調整 できる
• まだ 実験的な機能 のため、コマンド方式やエラー処理などが変更される可能性がある

---

概要

uvの最新リリース（0.8.13）は、Python開発者が長く待ち望んでいた実験的コマンド uv format を導入した。この機能により、プロジェクト内で別途フォーマットツールを管理しなくても、uvだけでコードスタイルの整理 を行える。

uv formatとは？

• uv format コマンドは uvインターフェースを通じてPythonコードのフォーマット を提供する
• 内部的には Ruffフォーマッタ を呼び出してコードを自動的に一貫性のある形に整える

開発者向けメモ

Charlie Marsh（uv開発者）はHacker Newsで次のように説明している。

Ruffとuvが統合されるわけではなく、依然として別個のツールである
単に、ユーザーがフォーマッタを別ツールとして意識せずに利用できるよう体験を向上させることが目的である
Rustエコシステムにおけるcargo fmtとrustfmtの関係に近い

使い方

• uv 0.8.13以上のバージョンを使用する必要がある
• プロジェクトルートで uv format コマンドを実行すると、ruff format を実行するのと同じ効果がある
• 実行方法はuvのコマンドインターフェースに従う

追加引数の受け渡し

• uv format -- [追加引数] の形で Ruffに渡す詳細オプション を設定できる
• uvの使いやすさとRuffの細かな設定を同時に活用できる

実験段階の案内

• 現在の機能は 実験的な段階 にあり、今後コマンド方式やプロジェクト構造との統合方法が変わる可能性がある
• エラー処理や出力形式なども継続的に改善される予定である
• ユーザーフィードバックを反映して機能が進化していく見込みである

まとめ

• Pythonプロジェクトで 手軽かつ一貫性のあるコードスタイリング が必要な場合、uv format を積極的に試してみる価値がある
• 実験的導入 であるだけに、実際に使ったうえでフィードバックを提供すれば、今後のuvの発展に貢献できる

[GN⁺]

Hacker News の意見

• ruffはtyと統合されたほうがよい気がする。uvはパッケージやプロジェクト管理に集中するのが筋で、コードスタイルの編集にまで関与すべきではないと思う。uvがコードファイルを変更する唯一のケースは、依存関係の更新（PEP 723）のときだけであるべきだと考える
  • ruffとuvは統合されるわけではなく、今後も別個のツールのままだという点を明確にしたい。これは、フォーマッターを別途気にしたくないユーザーによりシンプルな体験を提供するためのものだ。RustのCargoでcargo fmtが内部的にrustfmtを実行するのと似た構成である
  • Rustのcargoにcargo fmtがあるのと同じやり方をなぞっているだけだ
  • 本質的には、uvを完成形のPythonパッケージマネージャーにするのが目標であり、各構成ツールは必要であれば個別にも使えるようにするということだ。つまりuvはPython向けのcargoのような存在であり、高速な型チェッカーだけが必要ならtyだけ、フォーマッター／リンターだけが必要ならruffだけを選んで使えるべきだという点で、ruffとtyを統合する意味はあまりないように思える
  • もし将来的にtyもuvに統合されることがあるならどうなるのかも気になる。いずれもastral.sh発である以上、それがビジョンなのかもしれないが、まだtyは十分に成熟していない
  • 次の段階としては、uv lintのようなオプションを導入して内部的にtyを実行するようにするのが論理的な進化だと思う。理想を言えば、1つの標準コマンドまたは一連のコマンドでPythonプロジェクトの準備（フォーマット、lint、テスト、デプロイ）を行えるようになるとよい。おそらくそれがここに込められたビジョンなのだろう
• uvは本当に気に入って使っているが、不必要にだんだん肥大化しているようで少し心配だ。たとえば多くのサブコマンドが非常にたくさんの独特なフラグをサポートしており、中にはほぼ同じ結果になるものもある（uv run --no-projectとuv run --activeなど）。むやみに新機能を増やすよりも、既存ツールとドキュメントの改善にもっと集中してほしい
  • Pythonプロジェクトを安定的で再現可能かつ移植性のあるものにするのは本当に難しい作業だ。uv syncは理論上、再現可能なパッケージセットだけをビルドするので非常に有用だが、torch-tensorrtやflash-attnのような複雑なパッケージは環境に左右されざるを得ない。Pythonコミュニティはしばしば「自分のマシンでは動く」という形で問題を個人化しがちだが、ソフトウェアを配布・安全・反復可能・信頼性の高いものにするためのコストは決して消えず、結局は誰かが後になってより制約の強い状況でそのコストを払うことになる。こうした多様なユーザーと運用要件をすべて満たそうとするのは本当に難しい
  • uvにサブコマンドを追加することが、なぜ肥大化と見なされるのかよく分からない。もともとuvは複雑なツールであり、ドキュメントもしっかりしている。このように直感的で自己説明的なコマンドなら、追加されても十分自然だと思う
  • uvについて話すとき、「makeコマンドにはターゲットが多すぎる」と言っているのに近い感覚がある
  • これらのオプションがメイン実行ファイルに組み込まれるのか、それともaptやcargoのように別バイナリとして動くのか気になる
• このアップデートは明らかによい選択だと思う。なぜ多くの人がよりよい方向に反対するのかよく分からない。もちろん「少し不便な方法で既にできる」というのはその通りだが、それはあくまで『少し不便な』方法なのだ
  • 「uvx ruff formatは1語長いだけなのだから問題ない」という意見にはあまり同意できない。むしろ実際に何のフォーマッターが動くのか不明確になったり、ruffが自動でインストールされるのか、従来どおりツールをダウンロードしてキャッシュするのかが、かえって分かりにくくなる可能性がある
  • 強く共感する。pyprojectでフォーマッターを設定できるようにしてくれたらなおよい
  • 最大の不満は、現状では他のフォーマッターをサポートしていないように見えることだ。自分のプロジェクトでblackを使っているなら、uv formatは動かない
• 個人的には、この変更によって自分の小規模チーム（数理担当者が中心メンバー）のコードフォーマットが飛躍的に簡単になるのではと期待している。uvがPython導入とオンボーディングに与えた影響もかなり大きかったので、コード品質をもっと簡単に引き上げられる方法はいつでも歓迎だ。もちろんruffだけを別で使ったり、pre-commitを構成したりもできるが、uv <機能>という単純なメンタルモデルはチームにとって大きな助けになる。他のフォーマッターとも連携できるようになればよいし、もしSQL/dbtモデルのフォーマットまで対応してくれたら言うことはない。まずは使ってみて可能性を確かめたい
  • それほど多重フォーマットが必要なら、Makefileやjustfileのようなものを使うほうがよいかもしれない。そうすればjust formatでPython/SQL/Bash/TypeScriptをまとめてフォーマットできる
• やや機能過多に感じる。1年以上uvを徐々に多く使うようになり、その利点も分かってはいるが、いまだに自分の最優先の選択肢ではなく、こうした変化で好みが高まるとも思えない
  • 具体的に何が問題なのか気になる。Go、Rust、Elixirはいずれもこうした方式を採用しており、それぞれの言語エコシステムでプロジェクトの設定や利用をずっと容易にしている。コミュニティが共通ツールセットに集中でき、初心者と上級者の双方に一貫した入口を提供できるという利点がある
  • もしそうなら、どのツールを一番好んで使っているのか気になる
• いずれruffの機能はuvとtyに統合される気がする。lintはコードベースをより深く理解できるtyが担当すれば賢くなりそうだし、フォーマットはプロジェクト管理を主目的とするuvが担うのが適している
  • tyはすでにruffと同じリポジトリにあるので、統合もそれほど遠い話ではなさそうだ
• パッケージマネージャーは運用環境向けのパッケージ導入には必須だが、開発専用ツールと混ざるのは一種の「魅力的だが危険な罠」のように感じる。もちろんGoやRustもそうしているが、根本的に考えるとあまりよい構造ではない気がする
  • かなり悪く聞こえるかもしれないが、cargoをたくさん使ってきた立場からすると、こういう「よくないアイデア」はもっと増えてほしい。もしuvがPythonにおけるcargoのような役割を果たすようになれば、Python開発体験は劇的によくなるはずだ。25年以上Pythonを使い、数々の不十分な部分を乗り越えてきた身としては、今や深く考えずにuvひとつで済ませられるのは非常に満足度が高い
• 新しいuv formatは、実質的にはuv run --with ruff ruffのショートカットだ
• この流れは本当に気に入っている。もし自分の意図どおりにするなら、uv fmtという名前にして、uv vetのようなものもロードマップに加えるとよいと思う
• すでに実績のあるコードフォーマッターツールはたくさんあるのに、あえてこれを導入する理由はまったく感じない。機能だけが増えた印象なので、しばらくはどのパイプラインにも組み込むつもりはない
  • uv formatは単にruff formatのフロントエンドに近いだけで、新しいフォーマッターが追加されるわけではない
  • すでに多くの人が使っているruff formatを手軽に使えるようにするショートカットにすぎない、という点は知っておいたほうがよい