2 ポイント 投稿者 GN⁺ 2024-08-23 | 1件のコメント | WhatsAppで共有

Armin Ronacherの考えと文章

PythonパッケージングのためのRyeとuv: 8月は収穫の季節

  • 数か月前、Ryeパッケージングツールの管理権をAstralに引き渡した
  • Astralチームはここ数か月、Pythonパッケージングのための多くのツールを開発してきた
  • 最近のリリースで、uvはpyproject.tomlファイル操作、ワークスペース対応、ローカルパッケージ参照、スクリプトインストールなどの機能を追加した
  • uvはPythonのインストール管理もできるようになり、Ryeと非常によく似たものになった
  • Ryeを使っている人はuvに注目し、フィードバックを提供するべきだ

EuroPythonでの発表

  • 最近プラハで開かれたEuroPythonで、Pythonパッケージングに対する見解と、Ryeを作りながら学んだ教訓を発表した
  • パッケージングツールの目標は、誰もが使う最高のツールになることだ
  • PythonはAIとMLへの投資と関心のおかげで、非常に人気の高いプラットフォームになった
  • Pythonを学ぶ人たちに、優れた開発者体験を記憶してもらいたい
  • 現在はツールが多すぎることと不一致のために難しさがある

ツールの支配

  • 支配とは、投資の大半が1つのスタックに注がれることを意味する
  • Ryeのようなツールは、支配的なツールが確立されたら消えるべきだ
  • uvがそのツールになる可能性が高い
  • 最終的にRyeはuvに置き換えられるだろう

パッケージングエコシステムの発展

  • 多くのパッケージングツールは、Pythonエコシステムの発展を土台として構築されてきた
  • setup.pyファイルからeggs、wheelsへの移行、メタデータ標準の導入など、多くの進展があった
  • Rust cratesとPythonライブラリの発展が、こうしたツールを可能にした

コミュニティの次の段階

  • コミュニティは、より少ない数のツールを推奨すべきだ
  • ez_setup.pyeasy_installを推奨していた時代があった
  • 現在はpip、pip-tools、poetry、PDMなどを推奨している
  • 重要なPythonプロジェクトを保守している人たちは、uvを試し、推奨するかどうか検討すべきだ

AstralのVC資金

  • AstralがVC資金を受けていることが、今後どのような影響を与えるか考える必要がある
  • コードとuvの機能を見る限り、最悪の場合でもコミュニティはuvが存在する前より良い状態になるだろう

GN⁺のまとめ

  • この記事は、Pythonパッケージングツールの発展とコミュニティの役割を扱っている
  • uvは多くの機能を提供しており、Ryeを置き換える可能性が高い
  • コミュニティは、より少ない数のツールを推奨し、uvを試してみる必要がある
  • AstralのVC資金が今後に与える影響を考慮する必要がある
  • 類似した機能を持つツールとしては、pip、poetry、PDMなどがある

1件のコメント

 
GN⁺ 2024-08-23
Hacker Newsの意見
  • uvの最新リリースにより、Home Assistantのリリースプロセスが大幅に短縮された

    • リリース時間が約2.5時間から約20分に短縮
    • 詳細はHome Assistant開発者ブログで確認できる
  • 当初は新しいツールがPythonの「パッケージング」問題を解決してくれることを期待していたが、実際にはパッケージ管理に関するものだった

    • 個人的にはPythonのパッケージ管理に大きな問題はなかった
    • pipは一般的によく動く
  • Pythonではアプリケーションを実行ファイルとして簡単にパッケージ化できないのが不便

    • 本番環境でgit cloneしてvirtualenvを作成するのをよく見かける
    • これはセキュリティの観点からよくない
  • Pythonのパッケージングには問題があるが、基本のpipでもかなりうまくやってこられた

    • もともとvirtualenvから組み込みのvenvモジュールへ移行したのが大きな変化だった
    • 依存関係管理を本気でやるなら、FAANGのようにモノレポを構築するのがよい
  • npmのVC詐欺やMicrosoftによる買収、OpenAIの法的な非営利ステータスの件により、主要言語のインフラをこうした組織に任せることに気が進まない

    • 個々の貢献者は素晴らしいが、組織レベルでの財務的な整合性が問題
    • 高速なlint、型チェック、コードスキャン、PRアシスタントはいつでも置き換えられるが、インストールフローやパッケージリポジトリはそうではない
  • こうしたツールの問題は権威性にある

    • pypaの承認を得ていないため、cargoとは異なる
    • pypaは包括的なソリューションを提供できていなかった
    • 3〜4年前まではpoetryやpipenvが問題を解決してくれるように見えた
    • pypaはastral.shに関与すべきだが、支配せずにそれができるのかは疑問
  • Arminは「uv」がこの分野を支配すべきだと主張しているが、VC支援によって問題が起こり得ることも認めている

    • 彼の解決策は「uv」が非常にフォークしやすいことだというもの
    • しかしフォークはさらなる分裂を招く
  • 会社ではpoetryの遅さのため、ソフトウェアをuvへ移行しようとしている

    • 多くの文書を読んだが、実際にできたことはあまり多くない
    • 以前のpoetryへの移行ははるかに簡単だった
    • uvは依然としてPythonパッケージの多くの問題を抱えたままである
  • 人々が今回のラウンドを見送り、2026年の「Pythonパッケージマネージャー: 今度こそ本当に解決した!」を待つのも理解できる

    • それでもNixユーザーは満足している
  • パッケージマネージャーの開発に情熱を持つ人たちがいる

    • この状況が続くなら、毎年新しいパッケージマネージャーが登場するだろう