ハクソク

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

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

277日前原文(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 formatはruff formatのフロントエンドに過ぎないよ。新しいフォーマッターをエコシステムに導入してるわけじゃないし。

むしろruffをtyと統合してほしいな。自分にとってuvはパッケージ／プロジェクトマネージャーの役割だから、コードスタイルのことじゃない。uvがコードファイルを編集するのは依存関係を更新する時（PEP 723）のみでいいと思う。一方で、ruffとtyはコードスタイルに関するもので、コードを編集してフォーマットしたり、タイプやリントの問題を修正したりするから、統合するのに良い候補だと思う。

└

Rustのcargoを真似してるね、cargoにはcargo fmtがあるし。

└

でも、もしtyも最終的にuvに統合されたらどうなるんだろう？8-) astral.shの情報からするとそれがビジョンかもしれないけど、tyはまだ準備が整ってないね。

└

これは予想通りの方向性で、特に好きなわけではないけどね。UNIX哲学のツールを使い続けるつもりだよ、ありがとう。

└

目標は、uvをPython用の完全なパッケージマネージャーにすることだと思うけど、同時にそれぞれのパーツを別々に使う選択肢も残してるんだ。uvはPythonのためのcargoみたいなもので、もし速い型チェックだけが必要ならtyを使えばいいし、速いフォーマッターとリンターが必要ならruffを使えばいい。ruffとtyを組み合わせるのは、こう考えると意味がないよね。

└

ちょっと説明すると、ruffとuvは統合されないよ。それぞれ別のツールのまま。これは、フォーマッターを別のツールとして考えたくないユーザーにとって、よりシンプルな体験を提供することが目的なんだ。Cargoの例えで言うと、cargo fmtはただrustfmtを実行するけど、別にrustfmtを単独で実行することもできるよ。

└

お願いだからやめてくれ…現実はエコシステムは進化するってことだよ。最初はmypyがあった。その後、pyreやpyrightなどのタイプチェッカーが出てきた。そしてbasedpyrightも。Rustの時代が来て、今はtyやpyreflyが盛んに開発されてる。リンターの側ではflake8やblack、そしてruffが登場した。デカップリングすることで進化への適応がずっと楽になる。両方がLSP統合を提供し続ける限り、エンジニアは最適なものを選べるようになる。

└

次の論理的なステップとして、ここにuv lintオプションを追加して、内部でtyを実行するようにするのがいいんじゃないかな？ Pythonプロジェクトを準備するための標準的なコマンドが一つかセットであればいいなって思う（フォーマット、リンティング、テスト、公開）。これが目指してるビジョンなのかもね？

これは明らかに素晴らしい動きだよ。なんでこんなに多くのコメントが改善に反対してるのか分からない。「もうやっちゃえばいいじゃん？」って。まあ、そうなんだけど、ちょっとだけ悪化してるんだよね。

└

一番の問題は、他のフォーマッターをサポートしてないみたいなところだね。もしプロジェクトでblackを使ってたら、uv formatは使えないってことになる。

└

一単語長いからって（「uvx ruff format」と「uv format」）悪いとは思わないな。実際に動いているフォーマッターやその実行方法を隠す特別なケースを作る方がずっと悪いと思う（ruffは今やプリインストールされてるのか、それとも他のツールと同じようにダウンロードしてキャッシュされるのか？）。

パッケージマネージャー（本番用のパッケージインストールに必要）と開発専用のツールを混ぜるのは、「魅力的な迷惑」みたいなもんだと思う（誰かを子供扱いしてるわけじゃないけど）。GoやRustがそうしてるのは知ってるけど、基本的な考え方からすると、あんまり良いアイデアじゃない気がする。

└

確かに悪いアイデアに聞こえるけど、cargoをたくさん使った今、もっとそういう悪いアイデアが欲しくなってきた。マジで、もしuvがPythonにとってcargoのような存在になったら、Pythonの開発者体験は今までよりずっと良くなると思う。25年以上Pythonをプロとして書いてきて、そのクソみたいな部分を避けながらお金をもらってたけど、もうその知識を捨ててuvを使えるのが嬉しい。

これで小さなアクチュアリーのチームがコードをフォーマットするのがずっと楽になると思ってる。uvが私たちのPythonのオンボーディングや活用に与えた影響はすでに大きいし、彼らのコードの衛生状態を簡単に改善できる方法はどれでもいい。ruffをスタンドアロンで使わせることもできるし、プレコミットフックを設定することもできるけど、uvから得られるシンプルなメンタルモデルが本当に役立つ。これを試してみて、どうなるか見てみるつもり。できれば他のフォーマッターにもフックインできるといいけど、それが簡単かどうかも分からない。例えば、uv formatが私たちのSQL/dbtモデルもフォーマットしてくれたら最高だな。

└

その時点で、Makefileが欲しくなると思うし、できればIMOではjustfileがいいかな。そしたら、just formatを実行するだけで、Python/SQL/Bash/TypeScriptのプロジェクトを一気にフォーマットできるよね。

そのタイトルは、HNが自動で削除した括弧なしの方がずっと面白かったな。