「uv」は爆速で最高だけど、パッケージ管理のUXがカオスすぎる件について

Python界隈で話題の「uv」、確かに爆速で素晴らしいツールですよね。でも正直なところ、パッケージ管理周りのUX（ユーザー体験）がかなり複雑で、使いにくさを感じていませんか？直感的に扱えるようになるには、まだ少し改善の余地がありそうです。

“is a mess”（ひどい有様）

と言いつつ、引数を2つ余分に書かなきゃいけない例を挙げてるだけだよね…

もっと適切なタイトルは「UVに期待するQOL向上」じゃないかな。

上限（upper bound）がないことに注目

uvには単一の解決（singular resolution）が必要だから、それは完全に意図したものだよ。npmならツリーの場所ごとに異なるバージョンをインストールできるけど、Pythonにはその選択肢がない。Ryeを作っていた時も同じ決断を迫られたけど、これ以外にベストな解決策はないんだ。

もし上限を指定できるようにしたら、実運用では解決不可能な依存関係ツリーが出来上がるのがオチだ。Pythonのエコシステムには、不適切な上限が設定された古いパッケージに対して、無理やり上書き設定を公開するようなケースすらあるからね。

今の時点で、自分のパッケージが未リリースの未来のパッケージと互換性があるかどうかなんて誰にも分からないってことを忘れないでほしい。

興味深い視点だし、フィードバックは良いことだと思う。記事全体の意見には同意するけど、批判の激しさについては少し納得がいかないかな。

プロジェクト内にコマンドランナーを導入すれば、著者が指摘した問題の多くは隠蔽できる。中規模以上のプロジェクトでコマンドランナーを使うのが便利なのは経験上知ってるけど、UX上の問題をツールで隠蔽しなきゃいけないこと自体に問題があるとも言えるね。

uvのバンドワゴンにはつい最近乗ったばかりなんだ。普段は古いPythonプロジェクトのメンテナンスばかりで、新しいビルドに使う程度。速度向上は歓迎だけど、そこまで大騒ぎするほどのことかな？ってのが正直な感想。仕事柄、人気ツールを使うことにメリットがあるから使い続けているだけで、他のツールでは絶対にできなかったことができるようになったわけじゃないしね。一つのツールに全ての機能を詰め込むのがプラスかマイナスかは、結局好みの問題じゃないかな。

個人的に気になっているのは、このサイクルを何度も見てきたこと。新しいツールが「これまでのツールより圧倒的に優れている、速度が命だ、既存のやり方は全部ダメだ」と言って登場する。たとえ、その新しいツールが古い「ダメな」ツールの機能のほんの一部しか持っていなかったとしてもね。で、採用が進むと機能や要求が増えていって、結局古いツールと同じようなものに変化し、かつて「ダメだ」と批判していたのと同じ欠点を抱えるようになる。今回のUXの問題も、そのプロセスの兆候に見えるんだよね。

uvは今でも良いツールだと思うよ。Poetryも使ったし、昔ながらのpipも使ってきた。どれも良いツールで、それぞれ適したユースケースがあるだけ。pyenvが必要な時もあれば、いらない時もある。direnvも同じ。どれを使ってもイライラさせられることはあるしね。ただ、uvに対する熱狂的な信者ぶりはかなり強烈で、正直なぜそこまでなのか不思議に思うよ。

（注意：私はuvの開発者です）

クリックベイト的な書き方ではあるけれど、有用なフィードバックも多いと思う。いくつか考えを述べるよ。

• pnpm outdated について：これは私にとって妥当そうに見えるのに、これまであまり出てこなかった話題だね。PythonとJavaScriptの文化的な違いによるものだと思う。私の感覚だと、依存関係が脆弱性を持っていたり壊れていたりしない限り、Pythonの依存パッケージが古くなっているかを「気にする」機会が思いつかない。対照的にJavaScriptエコシステムでは、積極的にアップデートしていくのが一般的なようだ。これが悪いとは言わないけど、プログラミングコミュニティ間で、CLIに何を提示すべきかという直感に断絶があることを示す良い例だと思う。

• Arminの指摘1の通り、uvの上限設定の挙動は意図的なもの（Pythonの解決メカニズムにおいて機能的に不可欠なもの）。これは他の言語と比較した際、Pythonが払っているトレードオフだけど、正直良い選択だと思う。依存ツリーの中に各依存関係が一つずつ存在し、相互依存するすべての要件がそのバージョンで解決されると分かっている状態が好きなんだ。

• uv lock --upgrade が今の書き方になっているのは、ユーザー自身の要件（requirements）ではなく、ロックファイルをアップグレードするためだよ。対して pnpm update はユーザー自身の要件（package.json）を更新するように見える。混乱する理由は分かるけど、uv lock の下に置く方がより厳密だと考えている。そうでないと、「なぜ uv upgrade を実行しても、自分が意図するアップグレードが起きないんだ？」とユーザー間で直感が食い違って混乱するからね。とはいえ、より分かりやすく提示できる部分は確かにあるし、要件ファイルを直接アップグレードするサブコマンドを求めるユーザーの声があることも理解しているよ。