Rye: 手間のかからない Python 体験

 (rye.astral.sh)
2 ポイント 投稿者 GN⁺ 2024-07-10 | 2件のコメント | WhatsAppで共有
  • Rye は、Python のインストール、pyproject.toml プロジェクト、依存関係、virtualenv、グローバルツールのインストールを一か所で扱おうとしたプロジェクト・パッケージ管理ツール
  • 現在は 開発中止 となっており、同じメンテナーたちが作った後継プロジェクト uv の利用が推奨される
  • 既存ユーザーは uv migration guide を参考に移行でき、Rye は引き続き利用できるが、これ以上の更新予定はない
  • 更新停止には セキュリティアップデート も含まれるため、新規プロジェクトや長期保守環境では uv への移行を検討する必要がある
  • Rye が目指していた統合 Python 体験は、複雑なプロジェクトや monorepo まで含んでいたが、メンテナンスの中心は uv に移っている

Rye の現在の状況

  • 開発中止と uv 推奨

    • すべてのユーザーに uv の利用が推奨される
    • uv は同じメンテナーたちが作った 後継プロジェクト である
    • uv は活発にメンテナンスされており、Rye よりはるかに広く使われている
    • 既存の Rye ユーザーは uv migration guide を参考にできる
    • Rye は引き続き利用できるが、追加の更新予定はない
    • セキュリティアップデートも予定されていない

Rye が提供していた機能

  • Rye は Python 向けの プロジェクトおよびパッケージ管理ソリューション
  • Python ユーザー向けのワンストップツールを目指して作られた
  • 1 つの統合された体験の中で、次の作業を扱う
    • Python インストール管理
    • pyproject.toml ベースのプロジェクト管理
    • 依存関係管理
    • virtualenv 管理
    • グローバルツールのインストール
  • 複雑なプロジェクトや monorepo を扱えるように設計されていた
  • 紹介動画は Watch an introduction で見られる

関連記事

2件のコメント

 
lum7671 2024-07-11

私は少し前から、あれこれ試した末に
Introduction - PDM
を使っています。

Rye も使ってみないといけませんね。
 
GN⁺ 2024-07-10
Hacker News の意見

  • コアなパッケージング開発のかなりの部分はいまや uv で進められており、Rye は内部的に uv を使っているため、uv が良くなれば Rye も一緒に良くなる
    たとえば最近 uv に ユニバーサル依存関係解決が追加され、現在実行中のシステムだけでなく、すべてのプラットフォームとオペレーティングシステムで動作する単一の解決結果としてロックされた requirements.txt を作れるようになり、最新の Rye もこれをサポートしている
    https://github.com/astral-sh/uv
    Rye と uv を開発しているので、質問があれば答えられる

    • Rye/UV の ユニバーサル依存関係解決が PyTorch でも正しく動くのか、それとも Poetry と同じ問題に遭遇するのか気になる
      https://github.com/python-poetry/poetry/issues/6409
      https://news.ycombinator.com/item?id=39257501
    • クロスプラットフォームのロックファイルに向けた作業や計画を追えるのか気になる
      私の所属チームが移行をためらっている理由の一つがこの点。ML 作業をしているので PyTorch ベースのプロジェクトを例にすると、望ましい状態は、すべての依存関係を pyproject.toml に置き、AArch64 Mac や AMD64 Windows ワークステーションから次のプラットフォーム設定用のロックファイルを生成できること：デフォルトの MPS PyTorch を使う Mac、CUDA PyTorch を使う Windows、CPU PyTorch を使う AArch64 Linux、CPU PyTorch を使う AMD64 Linux、CUDA PyTorch を使う AMD64 Linux
      Ruff を作ってくれてありがとう。リンティングとフォーマットの両方にとても満足している
    • 素晴らしい仕事。以前は新しいコンピュータでプロジェクトの作業環境をときどき構築する必要があり、pyenv+venv+pip がいつもつらかったが、今は Rye に移行した
      今では Rye をインストールし、GitHub から取ってきて、rye sync と入力すれば終わり
    • uv と rye の両方を担当しているなら、なぜ二つを同時に維持しているのか気になる。分裂と選択の負担から来る混乱を避けるには、いま rye を終了するほうがよいのではないかと思う
    • 予測可能で性能の良いビルドを重視する企業が多く移行してきており、その過程で guac のようなツールに入れるための SBOM 生成が頻繁に必要になっている
      https://guac.sh/
      https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
      最近追加された依存関係の固定解除機能のおかげで、開発中は互換性を保つよう促しつつ、再現性のために正確で明示的な requirements.txt を生成できるため、脆弱性管理や SBOM の段階が Poetry のようなツールよりずっと簡単になる
      似た理由で https://hatch.pypa.io/latest/why/ を使っており、uv と相性が良い点も気に入っている

  • Rye で気が進まなかった点は、非標準の Python ビルドの使用を強く推奨しているところ
    哲学ページ（https://rye.astral.sh/philosophy/）では、python.org の CPython ビルドはまったく不十分で、プラットフォームによって .msi インストーラしかなかったり tarball しかなかったりし、複数の Python ディストリビューションが大きく分岐して下位エコシステムにさまざまな問題を生んでいる、と説明している。そのためこのプロジェクトは indygreg のスタンドアロンビルドを使っており、いつか適切に管理され信頼できる Python ビルドが登場して、現在の混乱を置き換えることを望んでいるという
    その indygreg ビルドの情報は https://gregoryszorc.com/docs/python-build-standalone/main/ にあり、別の Python を選ぶことも可能：https://rye.astral.sh/guide/toolchains/
    ただ、私は彼らが言う問題をほとんど経験したことがない。python.org から入手した公式 Python ビルドも動いたし、ディストリビューションのパッケージマネージャでインストールした普通の Python も動いたし、公式 Docker コンテナイメージに含まれる Python も動いた
    その特殊なビルドも問題なく動くだろうが、非標準性のためにためらってしまう。動作上の特異点一覧まであるのに、問題のないものへなぜ特異点を追加するのか分からない。Rye の哲学がそのビルドを使うことにあまりにも積極的なのも、OS にすでにある Python をデフォルトで使う代替手段に比べて魅力を下げている

    • おそらくこういう状況を指しているのだと思う：古い CentOS のようなものを使う会社で働いていて、システムのパッケージマネージャは Python 3.6 より新しいものを提供せず、python.org の公式バイナリは実行時に glibc バージョンに関する解読不能なエラーを出す
      ソースから Python をビルドしようとすると新しいシステム依存関係が必要で時間もかかり、結局、欠けているヘッダーファイルについてのさらに分かりにくいエラーが出る。そのエラーを検索すると、上流の GCC が 2017 年に修正した問題を回避する ./configure フラグが見つかり、ともかく成功はする
      こうした3回のエラーや manylinux ビルド環境を経験したことがないなら、苦痛の世界を丸ごと避けてきたということ。Windows のインストールスクリプト作成や、そのページの「使用可能な CPU 命令の制限」のような部分も同じ
    • Python のビルド、パッケージング、配布には二つの極端がある。一つは王道で、もう一つは千本の刃が並ぶ廊下だ。ポータブル Python の提案が理解できないなら運が良かったのであり、ずっと王道に留まっていたということ

  • Python のソースコードを定期的にダウンロードし、標準的な本番向け最適化でコンパイルしたうえで /use/local/python${version} にインストールしているが、Python 3.7 が出た 2018 年以降、非常に一貫して動作している
    私の経験では、これらのコマンドはあまりに安定して一貫しているので、自動化してもよいほどだ。筆者が問題視している点や、根本的な不満が何なのか気になる

    • 「python.org の CPython ビルドはまったく不適切だ」というのは、おそらく古い Python バージョンのセキュリティリリースに macOS/Windows バイナリがないという意味かもしれない
      たとえば Python 3.10.14 のインストーラーは入手できず、最後の Windows インストーラーは Python 3.10.11、2023 年 4 月 5 日版だ
    • 同意する。PSF を支援すべきであって、新しい「正しい方法」を主張するのはおかしな立場だ

  • Rye が好きだ。掲げていることをそのまま実現していて、venv/Python バージョン/パッケージング全体の流れを実際に快適にし、pyproject.toml のような公式の Python の使い方に慣れている人にはほとんど透過的に感じられる
    そのうえ Python を Cargo のように感じさせてくれるし、Cargo も使いやすいツールだ

    • 私のように Poetry 系を避けて pip-tools に留まっていたなら、Rye 内部で使われている uv はそのまま置き換え可能なツールだ
      個人的には、pip-tools は Poetry や Pipenv よりはるかに優れた設計だったと思う。pip と virtualenv の両方に対して直交的で、そのどちらもすでに Python に長く含まれてきた流れだからだ。Rye は、反復的な改善を経た標準準拠のアプローチが勝つ姿だと言える
      Rust による速度向上に加えて、仮想環境をどこに置くか（.venv）と、複数の Python バージョンをどうインストールするかについて適切なデフォルトを与えてくれる点がよい。小さく見えるが、wheel が numpy のインストール問題を解決して以降は、こうした合理的なデフォルトと組み込みの pip-tools が、事実上欠けていたもののすべてだった。その意味で、バイナリ wheel が登場した後に Anaconda の存在理由が何だったのかも気になる
    • Python にはすべてに 1 つのやり方があると聞いて始めてみたが、インストールと環境管理の体験はめちゃくちゃだった
      今からでも改善しているというのはうれしい
    • 「Python を Cargo のように感じさせる」なら、それだけですぐ説得される。Poetry が丸一日かかっても依存関係を解決できず、pixi を試そうかと思っていたところだった
      Python のパッケージマネージャーは Google のチャットアプリより多い気がする
    • 「実際に快適にする」とはどういう意味なのか気になる。要約するのが難しすぎるのだろうか。Anaconda や Poetry で、ユーザー体験の面から特別な選択肢だと感じられた部分をあまり見つけられなかった
      それにキュレーションの面では、より大きく古い組織より小さな組織を信頼しろという提案は説得力を持ちにくそうだ。つまり、掲げていることが正確には何なのか気になる。私が読めるのは「よいパッケージマネージャーはよくて速くてよい」程度なので、比較や思想のページがあるとよい

  • HN の皮肉っぽさには時々驚かされる
    Rye が好きだ。Cargo や Hex のような他言語のパッケージマネージャーを使った後、Python にも似たシステムがないことをずっと残念に思っていたが、Rye はその渇きを完全に満たしてくれた。venv、Python バージョン、プロジェクト依存関係を管理するために複数のツールを入れたくない立場としては、Rye 1 つですべて処理できるのが本当にいい

    • conda を使ったことがあるのか気になる。conda と比べると Rye はどうなのか？
      Rye はまだ感覚がつかめていないが、conda でも venv、Python バージョン、プロジェクト依存関係の管理はうまくこなせる
    • 同意する。Rye は私にはうまく動いている。Python 用 Cargo が欲しかったし、今のところ私の観点では Rye はそれを達成している

  • 新しい Python 依存関係マネージャーに出会うのは、新しい JavaScript フレームワークを偶然見つけるようなものだ

    • 私の哲学は単純だ。配布可能なプログラムである必要があるなら単に Go を使い、ポートのようなものが不要なら Docker を使い、組織のみんなが使っている OS と Python バージョンが入ったコンピューターを IT チームか誰かが渡してくれるなら venv を使えばよい
      ポートを扱う必要があったり、プログラムを配布する必要があったり、ライブラリが C や OS の要素に依存しているなら、お金を受け取った後にコードベースを管理する必要も責任を負う必要もないコンサル仕事を始めるほうがましだ
    • そのとおり。Docker は 10 年ほど前に、すでに Python プログラムの配布と実行の問題を解決していた
      最近は Docker で CUDA と PyTorch も動かせる。こういうスレッドで誰かが「単に Docker を使えばいい」と言うと、よくある返答は「Docker を学びたくない」だが、Docker の経験がまったくなくても Python コンテナを立ち上げるのに 10 分で済む
    • そのとおり。ただし Poetry のようなものと違って、今回のこれは実際によい
    • 本当に深刻だ。ユーザーの立場では、これだけ何年も経っているのに標準がないのはもどかしい

  • pixi(https://pixi.sh/latest/) がよい。Python バージョンを固定し、conda と PyPI からパッケージをインストールでき、Rust で書かれている

    • 面白そうに見えるが、また別のエコシステムに本気で投資するのは難しく感じる。curl で取得して bash にパイプしろと言い、その次に任意のコマンド出力に対して eval しろというやり方は気が重い
    • リンクありがとう。conda より速いのか気になる
    • pixi は素晴らしい。conda を使っている人なら、pixi は Git/プロジェクトディレクトリに結び付いた環境を置く conda の代替として使え、devbox/devenv/flox に近い
      背景は少し複雑だ。Anaconda 社には Python で書かれた conda があり、オープンソースエコシステムである conda-forge は CI ビルドボットを備えた conda チャンネルだ。その後、同じ conda-forge の傘下で C++ 製の mamba が conda の代替として登場し、これは alias conda=mamba が動作すべきレベルの実質的なドロップイン代替だ。現在は conda も高速化のために libmamba をソルバーとして使っている
      その後 mamba の作者がこれを pixi として分離し、Rust で書き直しつつ、環境の場所と有効化の方法に関する思想を変えたが、conda 環境とは完全に互換性がある

conda は、conda チャンネルにない場合のようなケースでは、pip 経由での PyPI パッケージのインストールを常にサポートしてきており、pixi は uv 経由で PyPI パッケージをサポートしています。だから pixi は速いのです。ブログ記事によると、mamba よりもはるかに速くする別の最適化もあります
純粋な Python ではないパッケージを使うなら、conda 系が適しています。パッケージマネージャーの選択（conda/mamba/pixi）は二次的です
PyPI の問題は、門番役が不足している点です。そこに、純粋な Python ではないパッケージを標準的にパッケージングする方法が不足している問題が重なり、環境が漏れたり、特にソースだけを配布しながら setup.py でコンパイラまで含めて環境をブートストラップするようなおかしなことをすると、再現不能になります
conda 側では、conda-forge チャンネルがかなり優れた品質管理を行っています。制約条件、ライセンス、PyPI 配布物にライセンスファイルが欠ける問題、環境分離などを確認します。もちろん、誤ったバージョン制約を持つ PyPI の変更を自動マージする公式 bot をメンテナーが使えるので、完璧ではありません
現時点でどのツールも解決できていない問題は、PyPI 中心であることです。conda にないパッケージを扱わなければならず、パッケージのリリースも事実上、まず PyPI に出すことが強制されます
PyPI にしかないパッケージを conda 経由でインストールする場合でも、その依存関係の一部は conda にあるかもしれません。私の知る限り、PyPI パッケージの依存関係を満たすために conda パッケージを使うパッケージマネージャーはありません。手動で conda パッケージを追加して依存関係を合わせることはできますが、正しいバージョン制約が適用されないリスクがあります
オープンソースの Python パッケージを書くときも、設定が conda チャンネルだけに依存しているとしても、たいていはまず PyPI にリリースしなければならない、またはそうすべきです。conda-forge チャンネルへのリリースは、事実上 PyPI に存在することを要求するからです。だから私のような人にとっても、Rye は依然として有用であり、検討する価値があります

  • uv 側の人たち（https://astral.sh/blog/uv）がこの Armin プロジェクトの指揮を引き継いだ点は、知っておく価値があります
  • 紹介ページには “Rye is still a very experimental tool, but this guide is here to help you get started.” とあります
    このプロジェクトにはとても期待していますが、より成熟した段階になるまで待つつもりです。Astral チームが出してきた他のものはどれも気に入っているので、期待は大きいです
  • 私たちは openai-python ライブラリの開発に rye を使っており、とても良かったです
  • Rye は良さそうですし、Poetry もかなり楽しく使いましたが、Go の標準ツールの品質には本当に敬意を抱くようになりました
    Python プロジェクトを始めるたびに、依存関係/仮想環境管理の最新状況を学び直さなければならない感じがします