Gentoo開発者「uv-buildは使わないで」の訴えに海外で賛否
姉妹サイトの新着
Gentooのパッケージメンテナーが、Python用のビルドバックエンド「uv-build」を使わないよう呼びかけるブログ記事を投稿し、Hacker Newsで取り上げられて議論になった。uv-buildはRust製で、PyPI上ではmanylinux向けのバイナリとして配布されているが、全パッケージをソースからビルドする方針のGentooでは、依存するたびにuv-build自体を毎回コンパイルし直す負荷が生じるという。スレでは「バイナリを使えばいい」という意見と、「ソース主義を否定する理屈はLinuxの歴史そのものを否定する」という反論で割れた。
uv-buildを使わないでほしいという訴え
出典: blogs.gentoo.org / 元記事はこちら
SPARCのサポートを切るのが悪いことだとは思わない。そもそも今どきSPARCマシンを持っていてビルド検証できる人なんているのか？富士通も後期のコアではARMに移行したくらいだし。
無償でパッケージングに特別な関心を持ってやっている人たちがいて、そういう人たちはSPARCを気にかけているんだよ。
俺は古いIBMメインフレーム向けにバグ修正とテストをしてくれと頼んでくるDebianメンテナーを知ってる。¯\_(ツ)_/¯ そういう人たちは実在するけど、俺はサポートする気はない。気に入らないならフォークしてくれ！
uv-buildはバイナリ/実行ファイルとして配布されている。例えばPyPI上のmanylinuxホイールがそれだ。ユーザーやディストロの方針としてソースからビルドするなら、それは暗黙的に受け入れた結果だろう。大多数のコンピュータユーザーにとっては、バイナリをインストールする方が合理的だ。
それでも、ディストロが本来サポートしているプラットフォームで、しかもビルド対象のパッケージ自体はそのプラットフォームに対応しているのに、uv-buildだけがそこで動かずビルドもできない、というケースでは問題になる。
安全とは言えないプラットフォームからOpenAIのバイナリをわざわざインストールする人がいるか？
『uv-buildを1回実行して1リリースをインストールするたびに100ミリ秒かかるとして、Gentooユーザーはuv-buildの新バージョンを何度も何時間もかけてビルドし続けることになる』――そんな無駄を省く方法があればいいのに（棒）
CPython自体がRustを取り込みつつあることを知ったら、この人はどう思うだろうね。最近のPyConの講演でも話題になってた。
そうだね、あくまでオプションらしいけど、Rust推進派がこれ以上押し進めたらPythonはフォークすることになると思う。自分はそのオプションをオフにするつもりだ。
mgornyはそれを分かっているはずだよ。彼はDPOのスレッドにも参加して活発に発言している。結局、これはまさにサポート階層（tier）があるための仕組みだ。CPythonは、Cコンパイラがあるからといって全プラットフォームのサポートを保証するわけではないと、かなり前から明言している。
いい加減大人になって、普通の人みたいにバイナリをダウンロードする時期じゃないか。俺も『Linuxカーネルをソースからコンパイルすれば理論上3.5%速くなる』とかやってた時期があったけど、プロの開発者がソース信仰のホビイストに付き合う義理はない。
Linuxユーザーに『大人になれ』『普通の人がやるようにしろ』と言う歴史は長い。みんながその言い分に屈していたら、Linuxなんて存在しなかった。
そのよくある決まり文句自体、昔からそんなに正確だったとは思わない。今Gentooを使っている人でパフォーマンスのためだけに使っている人は見たことがない。Gentoo使いは自分のシステムを完全に制御・カスタマイズしたいからやっている。
いい加減大人になって、普通の人みたいにWindowsを使うべきじゃないか。プロの仕事の大半はWindows上で行われているんだから。
『Pythonパッケージングのいいところは標準化されていることだ』というけど、それが実際に信頼できるものなのか、ちゃんと分析した人はいるのか？
自分の経験では、Pythonのビルドバックエンドが組み合わせ的に増殖する問題に散々悩まされてきた。NixOSで扱うには、依存関係の奇妙な循環に対処するためのオーバーライドをあれこれ書く必要があった。
Gentooって、全部ソースからコンパイルするタイプのディストロだっけ？
Slackwareには申し訳ないけど、Gentooこそが『全部ソースからコンパイルするディストロ』の代表だよ。もう23年以上使い続けてる満足ユーザーだ！
そう。しかもNixOSと違って、バイナリキャッシュを作るためのビルドハッシュ計算もしていない。だから、たとえ他の人とまったく同じレシピでビルドしていても、本当に毎回ソースからビルドする必要がある。この自前コンパイルへのこだわりは正直よく分からないし、最近は（コンパイルが遅い）巨大なプログラムも増えてるのに。
そもそもGentooがそれを始めた存在で、それが他のディストロとの違いを生んだ理由なんだよね。
あなたはGentooが重要じゃないと思っているし、相手はビルドバックエンドなんてどうでもいいと思っている。向こうはただお願いしているだけで、誰も聞く義務はない。
これが向こうからのお願いだよ。
あるいはNix方式を採用して、よくあるバイナリアーティファクトをコンテンツアドレス方式のストアにキャッシュし、必要なときだけソースからビルドするという手もある。
言いたいことは分かるけど、現実的にはPythonパッケージ内部のRust化は今後1年でさらに強まっていくと思う（自分もそういうパッケージをいくつか手がけている）。だから、こうした煩わしさに対する体系的な解決策がますます必要になってくるはずだ。
まあ、それがきっかけでビルドキャッシュをもっと良くする作業をする羽目になったけど、同時に『できる限りPythonを使わないようにしよう』という気持ちも強まった。
それこそがGentooの存在意義そのものだと思うけど。
ああ、今はバイナリパッケージも用意されてるけどね。
わざわざ登録してこれを書き込んだのか？
まあ、もっともな疑問だよね。
Dockerコンテナを山ほど並べても、実際にはカーネル以外ほとんど何も共有できず、RAMを大量に無駄にする。RAMが安かった頃は問題にならなかったけど、今となっては……。
他サイトの新着
一つには、どこでも動く汎用ターゲット向けではなく、理論上は自分の持っているCPUに最適化できるという利点がある。
それはそうだけど、理論上はそのビルドを配布して自分でコンパイルする手間を省くこともできる。例えばnixpkgsは、かなり汎用的なターゲットでそれほど強い最適化フラグも使わずにビルドしているけど、少なくともそれを実現する仕組みそのものは存在している。
Gentooにもバイナリパッケージはあるけど、USEフラグを活用できない。
それはChromeOSやその系譜（COSやFlatpak、元CoreOSの後継）にとっても良い土台になった。
『普段はビルドバックエンドを依存関係として追跡していない……Gentooの「毎回ソースからビルドする」という性質がその結びつきを強制している』というのが分からない。これはGentoo側がビルドツールの依存関係をうまく扱えていないだけに感じる。GentooはGCCのマイナーバージョンが上がるたびに、依存関係に含まれるC/C++ライブラリを全部リビルドしているのか？
いや、してない。clangやLLVM、Rustでも同じ。でも新しいGoが出たときは、Goでビルドしたものは再ビルドされる。あと、Perlの大きな更新があるとPerl関連パッケージの再ビルドが起きる。
うろ覚えだけど、GCCの出力の再ビルドが推奨されるのは、コンパイラの『プロファイル』が変わったときだけだったはず。要するにABIの保証ができなくなるときだね。
厳密に言えば、本来そうすべきなんじゃないか？GCCが変われば、それがコンパイルするものすべてに差が出る可能性があるわけだし。
GentooはuvをどうやらPyPIからダウンロードしていないみたいだ。
どうやらuvのgitリポジトリから直接取得しているらしい。それなら今話題になっている調整(コーディネーション)の問題も解決できるはずだ。一度バージョンがそこに上がれば、そのまま残り続けるはずだから。
この話題の背景と論点
uvはRuffの開発元Astral社が作ったPython用パッケージ管理ツールで、Rustで書かれている。そのビルドバックエンドであるuv-buildも同様にRustバイナリとして配布され、PyPIのwheelを通じて各プラットフォーム向けに提供される。Gentooのような「全パッケージをソースからビルドする」方針のディストロでは、依存先にRust製ツールが入ると、ビルドのたびにそのツール自体のコンパイルコストが上乗せされる。さらにSPARCや古いメインフレームなど少数派アーキテクチャ向けのビルドが用意されていない点も問題視された。スレでは「少数派環境のサポートにどこまで労力を割くべきか」という論点と、「バイナリ配布前提の設計そのものが妥当か」という論点が絡み合い、意見が割れた。Python本体でもRust導入が進んでいるため、同種の摩擦は今後も増えるとの指摘も出ている。
※本記事は海外掲示板 Hacker News のスレッド「A plea not to use uv-build」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。