Ryeとuv: 8月はPythonパッケージング収穫の季節
(lucumr.pocoo.org)- 2024年2月にRyeの管理権がAstralへ移って以降、基盤となるresolver・installerであるuvが急速に改善され、Pythonパッケージングツール統合の有力候補として浮上している
- 最新のuvは
pyproject.tomlの操作、workspace対応、ローカルパッケージ参照、スクリプトのインストール、Pythonインストール管理まで含み、Ryeが担っていた領域を吸収しつつある - AI・MLへの投資でPythonの新規利用者は増えたが、パッケージングツールの選択肢が多く互換性にもばらつきがあり、開発者体験はいまだ一貫していない
- パッケージングエコシステムには、誰もが使う支配的ツールが必要であり、そうして初めて投資とドキュメントが1つのスタックに集まる。Ryeはuv中心への移行経路になる可能性が高い
- AstralのVC投資はPSFとPythonコアプロジェクトが考慮すべきリスクだが、uvは最悪の場合でもフォークと保守が可能なコードだと評価されている
Ryeからuvへ機能が集まる流れ
- 2024年2月にRyeの管理権がAstralへ移り、その後の数か月でAstralはPythonパッケージングツールを急速に改善した
- Ryeユーザーは、基盤となるresolver・installerであるuvがより良く、より速くなったことを実感できた
- 最新のuvは、以前はRyeが必要だった機能を直接提供し始めている
pyproject.tomlファイルの操作- workspace対応
- ローカルパッケージ参照
- スクリプトのインストール
- Pythonインストール管理
- 現在Ryeを使っているユーザーはuvを確認し、Astralにフィードバックを送る必要がある
Pythonパッケージングツールが1つに集約されるべき理由
- EuroPython Pragueでの発表は、Pythonパッケージングの現状と、Ryeを作る中で得た教訓を中心としている
- パッケージングツールの目標は、その領域を支配するツールになることだ
- 誰もが使うツールこそ、最良のツールであるべきだ
- Pythonに初めて触れる人が、プログラミングの旅を始めるときに出会うツールだからだ
- この2年間、PythonはAIとMLへの投資と関心に後押しされ、新規開発者にとって非常に熱く人気のあるプラットフォームになった
- 新規ユーザーがPythonを、古くてツールの悪い言語ではなく、優れた開発者体験を持つ言語として記憶することが重要だ
- しかし現在のPythonパッケージングは選択肢が多すぎ、ツール間の互換性も完全ではなく、各所の不一致が体験を揺るがしている
- あるユーザーは1つのツールに従って進んだ末に壁にぶつかり、スタック全体をcondaへ移したあと、また戻ってくる状況を経験している
uvが支配的ツールになる可能性
- ツールが支配的地位を持つということは、ほとんどの投資が1つのスタックに集まることを意味する
- Ryeとその周辺のさまざまなツールは、支配的ツールが確立されたら、もはや独立して存在しなくてもよい方向が望ましい
- 現在のuvは、その役割を担う可能性が最も高いツールだと評価されている
- まだすべてのユースケースを満たしているわけではない
- ただし、急速にその地点へ到達しつつあるように見える
- コミュニティが今、uvを中心に集まり始めるべき時点だ
- これは、このツールが永遠に唯一のツールになるという意味ではない
- ツールは生まれ、消えていくものだ
- 将来は別のツールが現れるかもしれない
Ryeの引退とPythonプロジェクト案内の変化
- 期待されるRyeの最終リリースは、Rye固有の機能を引退させ、ユーザーをuvへ移行させ、ほとんどuvのエイリアスのように動作する形になる
- Ryeを1つ引退させるだけでは十分ではない
- 現在のPythonでは複数のパッケージ管理手法が使われている
- コミュニティは、より少ない数のツールを案内すべきだ
- Ryeとuvは、その下にあるエコシステムの長年の発展の上に作られている
setup.pyからeggs、そしてwheelsへ移ってきた流れ- メタデータ標準の不在から、標準を持つ状態への移行
- 結合されたビルドシステムから、分離されたビルドシステムへの移行
- 再配布・ダウンロード可能なPythonバイナリを実現した取り組み
- 関連するRust cratesとPythonライブラリエコシステム
- コミュニティは、いつか一部のツールをもはや推奨しないと言う準備が必要だ
- 以前は新規開発者向けガイドで
ez_setup.pyとeasy_installが推奨されていた - その後、ガイドから
ez_setup.pyを削除し、pipへ置き換えた - 一部のプロジェクトでは
pip-tools、poetry、PDMを案内していた - 現在は、多様なツールのために5種類のインストール手順を同時に示すプロジェクトも多い
- 以前は新規開発者向けガイドで
- 重要なPythonプロジェクトのメンテナーは、uvを実際に試し、ユーザーにuvを案内できるか判断してみる必要がある
- AstralのCharlieが書いたuvが現在できることに関する記事は、uvの現在の到達点を示している
AstralのVC投資とコミュニティリスク
- uvを開発するAstralがVC投資を受けた企業である点は、避けられない論点だ
- コミュニティの立場から見ると、誰かが多額の資金を投じることは新たな課題を生みうる
- PSFとPythonコアプロジェクトはこの点を考慮する必要がある
- uvのコードと挙動を見る限り、最悪の将来でもフォーク可能で保守可能な対象に見える
- Astralが事業をたたむ、あるいはライセンス面で非常に疑わしい行動を取ったとしても、コミュニティはuvが存在する前より良い位置にいられるかもしれない
1件のコメント
Hacker Newsのコメント
uvの最新リリースは昨日も議論されていた: https://news.ycombinator.com/item?id=41302475
リンク先の記事は、そのリリースを見たRyeの作者が書いた見解である
uvに関心がある人向けに言うと、pipの代わりにuvを使うことでHome Assistantのリリース工程が大幅に高速化された
リリースにかかる時間は約2.5時間から約20分に短縮され、詳しくは https://developers.home-assistant.io/blog/2024/04/03/build-i... にある。ちなみに私はただのHAユーザーである
Pythonは軽く使う程度だが、いったい何をしてそんなに時間がかかったのかわからず、ばかげているように感じる
Pythonパッケージングに問題があるのはわかっているが、個人的にはこれまでplain pipだけでもかなりやってこられた
最大の変化は、もともとvirtualenvを使っていたのを組み込みのvenvモジュールに切り替えたことだった。本気で依存関係管理をやるなら、FAANG流にモノレポを作ってパッケージマネージャー絡みの煩雑さを避ける気がする
本番環境でPythonのモノレポを管理しているが、依存関係管理は地獄だ。Poetryのいくつかの新機能を適用しようとしているが、大規模モノレポを取り巻くエコシステムの状態はひどい
目標は「自分には十分」ではなく、Python開発者2人の組織から数百・数千人規模まで拡張できるパッケージと仮想環境の標準ツールが必要だ。そうでなければエコシステムが分裂し、バグや難解なドキュメントが増え、言語が効果的に発展し続けることが難しくなる
ただし、プロジェクトがどのPythonバージョンを前提に作られたのかを定義する方法がない。パッケージを作るなら複数バージョンでテストする必要がある可能性が高いし、インストール可能な配布パッケージではなく、数人の開発者で共有するコードのまとまりであれば、機械学習モデルの実行、クラウド関数のデプロイ、レポート生成のような作業では普通、Pythonのバージョンを1つに正確に固定したいはずだ
モノレポというアプローチが、numpyやpandasをリポジトリにコピーして入れておくという意味なのかも疑問だ
最初は新しいツールがPythonの「パッケージング」問題を解決してくれそうで期待したが、読み進めると、私が作ったPythonアプリケーションを梱包する問題というよりパッケージ管理についての話だった
個人的にはPythonのパッケージ管理に大きな問題は感じておらず、エコシステムに足りない点はあるものの、名前空間がないことなどを除けばpipはおおむねうまく動いている
本当にいらだたしいのは、Pythonアプリケーションを簡単に実行ファイル化してどこかに配布できないことだ。本番環境でgit cloneしてvirtualenvを作っているのをよく見るが、対象サーバーに必要以上の接続性が求められ、開発依存関係がOS上に残ることにもなる。セキュリティの観点では非常に悪い考えなので、この問題が解決するまでは、エンドユーザー向けや本番配布が必要な仕事では他の言語を好むだろう
そのためにはアプリケーションがユーザーに届けられ、そこでPythonを見つけ、その過程がユーザーに対して透過的でなければならない。Ryeを作ったときも、uvも同様だが、システムを壊さない形でPythonのインストールをサポートしようとした理由の1つがそれである
さらに進んだ形は、uvまで含めてその全工程を自動化することだ。今でも望むなら、curl to bashのインストーラーでuv/Ryeとアプリをアプリ専用の一時的な場所にインストールし、ユーザーのシステムを決して壊さないようにできる
いずれはこの過程が完全に透過的になり、ネットワークアクセスも不要で、Windows向けの.msiのようなものも提供されるとよいと思う。ただしその前提として、uvのようなツールが事前コンパイル済みのPythonと必要なすべての依存関係を、ユーザープラットフォーム向けの場所に任意に配置できなければならない
uvが将来的に提供できる最終的なおまけは、完全にパッケージ化された成果物であり、そうなればとても良いだろう。その一歩手前の段階だけでも、Python製のコマンドラインツールをユーザーに届ける体験は、もはやひどいものではなくなり得る。uvxを使ってもいいし、望むならuv自体を完全に隠すこともできる
たとえばOSごとのインストーラーを作るツールがあり、AndroidやiOS、ブラウザーのような特殊な場所に配布するツールも出てきている。もちろん特定のパッケージが特定の対象で動かないことはあり得るが、標準インターフェースがあるので、コードがどこかで実行可能なら、その対象向けツールが動作する成果物を作れるはずだ
npmのベンチャー投資ベースのラグプルとMicrosoftによる買収、そしてOpenAIが法的な非営利の地位でさえベンチャー投資ルートに絡むリーダーたちにとっては無力なマーケティングにすぎないと示したあとでは、中核経路にある言語インフラをこうした組織に渡すのは気が進まない
そこに貢献している個人はそれぞれ立派で、しばしば優秀でもあるが、組織レベルの金銭的利害は最初から汚染されている。1〜4年も経てば重要なのは組織だ。いわゆる「英雄として死ぬか、長く生きて悪役になるか」だ
だから高速なリンター、型チェック、コードスキャン、PR補助ツールは構わないし、いつでも置き換えられる。だがインストールの流れやパッケージリポジトリはだめだ
pipとcondaの現状を思うと残念だが、現実はこうだと思う
MicrosoftがPythonを所有しているが、公には見せていないだけだと思う
数年前、kubectl向けのPythonバインディングを作りたかったのだが、クロスプラットフォームで動かすにはCGoがすべてのプラットフォームでPythonと同じコンパイラを使わなければならないと分かった。ところがWindowsではCGOはMINGWを使い、PythonはMSVCを使う。当時あったPython開発メーリングリストで、なぜ「オープンソース」プロジェクトが独占的なコンパイラを使うのかと尋ねたところ、返ってきた答えはMSVCは歴史的な選択で、いまは変えられないというものだった。MicrosoftがPython FoundationにCIとビルドを回すための無料インフラを提供し、Pythonインタプリタ作業を行う開発者も提供しているからだという説明だった。つまりMicrosoftの従業員がMicrosoftの金でPythonインタプリタを開発し、ツールチェーンからMicrosoftのツールを外すなという指示を受けているという意味だった
年々状況は悪くなっていった。似たようなプロジェクトと同じく、成功がさほど実力のない人たちが権力を握る土壌を作り、Python FoundationやPyPAのような周辺プロジェクトは、有用なコードを寄与したからではなく、行動規範のページを書いたことでその地位に就いた人たちで満たされ始めた。この行動規範とポジション支配をめぐる終わりのない争いは、結局のところ古参のコントリビューターたちが去るか追い出される結果につながり、最近ではTim sortを作ったTimが禁止されることまで起きた
Microsoftは、手を入れたプロジェクトごとにいつもやる一般的なアジェンダを押し進め続けている。宣伝のために役に立たない機能を大量に追加し、プロジェクトがあらゆる方向に振り回されるようにし、とりわけ流行をできる限り追わせることだ。そのためPythonは、まったく別の型システムを持つ言語なのに機械学習風の型をできるだけ追加し、ネイティブライブラリを動的に貼り付けるのに半分ほど使われる言語なのに事前コンパイルやJITに執着している。要するに波かっこのないC#にしようとしているわけだ
Microsoftは、Pythonの所有を公に発表すれば多くの人が技術から離れると分かるほど賢いので、大々的には宣伝しない。だが開発者が自社ツールに依存するようにし続けており、いつかはその投資を回収しに来るだろう
だが、これまで出してきたものは本質的に「私たちが作ったシステムが私たちの役に立てないよう制約しており、それでもそれは私たちのせいではない」という感じのコントリビューターブログ記事を何十億本も並べたようなものだった
内部システムと内部政治にのめり込みすぎて、自分たちがなぜそこにいるのかさえ、もはや分かっていないように見える
だから誰かが実際にうまくやり遂げてAstralのように市場を席巻するなら、それこそがコミュニティである私たちが受け取るに値する結果だ
[1]: ここで言っているのは内部政治のことだ。妙な極右風の「DEI採用だ！」という騒ぎの話ではない
これらのツールにはまだ権威の問題が残っている
PyPAが承認したものではないという点がcargoとの違いだ。同時にPyPAは何年にもわたって包括的な解決策を出せず、Pythonのパッケージングと開発ツールは増え続けてきた。ほんの3〜4年前までは、poetryやpipenvがpip+virtualenvでは解決できないPythonパッケージングの問題を解決するように見えていた
今ではPyPAはastral.shの船に乗るべきだと思うが、ある程度の統制権なしにそうするかは分からない
私にはかなりの部分が個人的な関係によるものに見えたし、当時のPipenvは壊滅的だった。意図は良かったが、会社では広く使われる依存関係が比較的少ないリポジトリですら、ロックファイルを更新するのに1時間待たなければならなかった。まるで動かなかった
実務的にはPyPAが行っている難しい技術作業には大いに感謝している。だが今どのツール群を推奨しているかはあまり気にしていない。コミュニティが使っているものを使い、「公式」の提案は気にしないほうがよいと思う
参加者数が不明で、PyPAがコアPythonやPSFとどの程度関係しているのかもはっきりしない
実際に役に立つ承認は、コアPythonプロジェクトそのものから出るべきだと思う。理想的な世界なら、公式Pythonチュートリアルが「Pythonのインストール方法はこうです」から始まり、uvのインストールを案内し、公式Rustドキュメントがrustupとcargoを指しているのと同じであるべきだ
PSFがAstralと何らかの関係を築き、いつかこうした現実が可能になることを強く願う
この文脈ではおおむね無関係だと自ら証明したと思う。触るものすべてが腐っていくように見えるので、残念だがこの問題では距離を置いていてほしい。こう言うのはつらいし自分の哲学にも反するが、現状を反映した判断にすぎない。Pythonで10年間フルタイムで働いてきたが、ほかのパッケージング生態系は事実上、Pythonを一周以上追い抜いてしまった
もはや「PyPAの実行上の問題なのか、定められた役割範囲が間違っているのか」といったニュアンスも気にしていない。そういう議論に引きずり込まれるのにも飽きた
Armin は uv がこの領域を支配することを支持しているが、ベンチャー投資頼みなのでラグプルされうる点も認めている。
その潜在的な問題への解決策として「とても簡単にフォークできる」と言っているが、フォークは本質的にさらなる断片化を生まないのだろうか？ 彼が解決したいまさにその問題だ。
Python パッケージングの地形を支配しようとするツールなら、コミュニティ主導でコミュニティが統制すべきだと思う
ラグプルされたツールによっていったん統一された後の断片化の度合いは、統一前よりはるかに低いかもしれない。
それに、この想像上のコミュニティは、優れた支配的ツールを作るのにあと何十年必要なのだろうか？
今日の朝、会社で Poetry の遅さのせいで、私たちのソフトウェアを Poetry から uv へ移行することを検討していた。
これまでかなり文書を読んでいるが、実際にはあまり進展していない。以前 Poetry へ移行する作業も私がやったが、そのときのほうがずっと単純だった。今のところ見る限り、Poetry は他のパッケージマネージャのように動く単純なパッケージマネージャを作ろうとしていたのに対し、uv は Python パッケージングの狂気をかなりそのまま残しているように思える
Poetry の些細な変更で package.toml 形式が壊れたり、推移依存では動かないばかな
sourcesのせいで複数インデックスでの解決時間が長くなったりもしないuv は事実上、標準的な Python ツールの流れにそのまま差し込める感じだ
人々が今回は見送り、2026 年版の「Python パッケージマネージャ: 今度こそ本当に解決しました！」を待つとしても責められない。
それでも私は依然として満足している Nix ユーザーだ
このフレーミングは本当に気に入っている。
多くの人が長い時間をかけて段階的に積み上げてきた作業のおかげで、いまや 1 社の数人が中程度の努力で状況を劇的に改善できる地点まで来たのだ