- pyx は uv 開発チームが作った Pythonネイティブのパッケージレジストリ で、PyPI・PyTorch・プライベートソースからのインストール速度を 最大10倍向上
- 従来のパッケージレジストリの範囲を超え、速度・セキュリティ・GPU認識 機能を提供し、内部パッケージと PyPI・PyTorch のような公開ソースの両方をサポート
- パッケージの人気、作成時期、脆弱性の有無などの基準でフィルタリングできる 専用インデックスURL を提供し、セキュリティとコンプライアンスを強化
- Pythonに特化した 最新標準のサポート と uv との 直接統合 により、設定なしで認証と利用が可能
- チーム内の重複ビルド、PyTorch・CUDA インストールの難しさ、ビルド破損、認証の煩雑さなど エンタープライズ環境の主要な問題 をサーバー・クライアント統合で解決
- GPU認識機能 により、ハードウェアに合った PyTorch、vLLM、FlashAttention、DeepSpeed などの事前ビルド版を一貫したメタデータと最適構成で提供
- 最適化されたアーティファクトと uv ネイティブのメタデータ API により、他のプライベートレジストリと比べて卓越した性能を提供
Astralのビジョンと背景
- Astral は Python エコシステム向けの 高性能な開発ツール を作る会社で、Ruff（リンター・フォーマッター）と uv（パッケージマネージャー）でよく知られている
- 創業の背景には、Python が世界で最も人気のあるプログラミング言語であるにもかかわらず、ツール面で十分に支援されていない と感じたことがある
- 現在の Astral ツールチェーンは月間1億件以上のインストールがあり、uv は1日あたり5億件以上のリクエストを処理するなど爆発的に成長中
- 目標は Python を 最も生産的なプログラミングエコシステム にすることで、そのためにクライアントツールを超えて Pythonクラウド を構築しようとしている
pyx の紹介
- pyx は uv の最適化されたバックエンドとして設計された Pythonネイティブのパッケージレジストリ
- 内部パッケージをホスティング可能
- PyPI や PyTorch インデックスのような公開ソースに対する高速化・設定可能なフロントエンドとして機能
- 主な特徴
- 高速なインストール速度 : パッケージのインストールとビルドを最適化
- PyPI、PyTorch、内部プライベートソースからパッケージをインストールする際、最適化されたアーティファクトと uv ネイティブのメタデータ API を活用
- 他社のプライベートレジストリと比べて最大10倍高速
- セキュリティとコンプライアンスの強化 : 依存関係・サプライチェーンの理解を通じてリスクを最小化
- パッケージフィルタリング用の専用インデックスURLを生成可能
- 人気、公開からの経過期間、脆弱性の状態などの基準でパッケージへのアクセスを制御
- サーバー側で再現可能なビルドを保証
- 最新標準のサポート
- Python に特化した最新のパッケージング標準とワークフローをサポート
- uv と直接統合され、別途設定なしでスムーズに認証・利用可能
- GPU認識パッケージ配布 : CUDA・PyTorch 関連のビルドと配布を簡素化
- PyTorch、vLLM、FlashAttention、DeepSpeed など GPU 関連ライブラリのカスタム事前ビルドを提供
- ハードウェアベースの最適構成と一貫したメタデータを維持
解決しようとしている問題
- PyTorch・CUDA・FlashAttention・DeepSpeed など GPU 関連ライブラリのインストールの難しさ
- チーム内で同一パッケージを繰り返しビルドすることによるリソースの浪費
- setuptools の更新によるビルドエラー
- 内部レジストリの認証プロセスの煩雑さ
サーバー・クライアント統合戦略
- uv（クライアント） と pyx（サーバー） の垂直統合によって上記の問題を直接解決
- pyx なしで uv だけ、または uv なしで pyx だけでも利用できるが、一緒に使うと最高の体験 を提供
- オープンソースツールとの深い統合によって、これまで不可能だった開発体験を実現できる
ビジネスモデル
- uv、Ruff、ty など Astral のツールは 永久に無料・オープンソース・パーミッシブライセンス を維持
- その代わり、pyx のような 有料ホスティングサービス を提供し、「次の段階」のインフラ需要に応える
現在の状況と今後の計画
- 現在、Ramp、Intercom、fal のような 初期パートナー と運用中
- GA（一般提供）まで オープンビルド を通じて迅速なフィードバックループを維持
- 関心のあるチームやファンに連絡を呼びかけている
4件のコメント
この会社はどうやって収益を上げているのだろう、と思いながら読み進めていたのですが、
pyxを有料で提供する計画なのですね。All python packaging challenges are solvedだなんて、笑わせる話ですね。解決されたのではなく、ただ動くように片付けてあるだけなのではないですか（笑）。
Python は世界中で使われている主要言語なのに、環境があまりにも雑然としているのは事実です。
Hacker News のコメントでは「企業」が乗り出すことを心配していますが、企業が動くまで誰も気に留めなかったからこそ状況がここまで悪化した、という点は考えていないようですね。
参考までに: Hacker News のコメントで誰かが言ったことを引用
Hacker Newsの意見
たぶんこちらのブログ記事のほうが有用だと思う https://astral.sh/blog/introducing-pyx
Pythonパッケージングの問題はすべてすでに解決済みだ、という意見もある。ここでの教訓は、あらゆる問題にぴったり当てはまる単一の解決策など存在しないということだ。VC資金の入った企業との結びつきを強めたり、そうした企業のインフラに依存したりすることは、FOSSコミュニティにとって常に大きなリスクだ
最初はpipを使えと言われて始めた。でも遅いし、しょっちゅう問題が起きた。そこでvirtualenvに乗り換えたが、これは問題の一部しか解決しなかった。その後condaを使ったが、ときどきうまく動く一方で、shellのプロファイルがめちゃくちゃになり、パッケージのバージョンが衝突することも多かった。次にpipenvを勧められ、初期はよかったが、開発が放置され、人が入れ替わってからは最新バージョンで頻繁に壊れるようになった。その後またpoetryを勧められたが、遅すぎて使えなかった。そこでpipと標準のvenvに戻ったが、以前と同じ問題に再びぶつかり、機能もさらに少なかった。そこでuvに移ったが、これはまだちゃんと動いたほうだった。ただ、必要な依存関係はOSごと、GPUごとにビルドやパッケージング方法が異なるので、同僚たちはこのプロジェクトを自分のラップトップにインストールすることすらできない。Pythonパッケージングの問題が全部「解決」されているなんて、本当にありがたい話だ
「Pythonパッケージングの問題はすべてすでに解決されている」という主張は、率直に言って事情を知らないか、無知から出たものだ。Pythonには今なお、さまざまなプラットフォームでネイティブ依存関係を安定して扱う方法がない。pipとsetuptoolsがこのエコシステムの最終形であってはならない
懸念している点には同意するが、uvを使い始めてからものすごく時間を節約できているので、VCマネーの弊害で完全に壊されるまでは使い続けるつもりだ。その頃までには、コミュニティが一つの方向にまとまってくれるといいのだが
この3時間ずっとPythonとDebianの格闘をしていて、Pythonエコシステムへの怒りがこみ上げている。まったく解決されていない。Debianではvenvの使用ばかり推奨されるが、venvに入れたパッケージはcmake系のツールから見つけてもらえないことが多い。apt-getのパッケージもあるし、それしか見つけられないツールもあれば、逆にそれを見つけられないツールもある。パッケージ名にも一貫性がない。自分のコンソールはpipxを勧めてきたが、体験としては似たようなものだった。しかも昔のPython 2 vs 3の残骸がまだ残っていて、バージョン番号を含むかどうかの違いでパッケージ探索に失敗することがよくある。c++headerparserが何者かは知らないが、最終的にはPythonをビルドツリーから排除して、そのまま歴史の彼方に葬るのが正しいのだと確信するに至った
もしかして初めて来たの？ じゃあこのKool Aidをどうぞ。グラスに入っている「MongoDB」のロゴは気にしなくていい。昔のものだから
オープンソース製品を何度も信じて傷ついた経験がある。こういう約束は数えきれないほど聞いてきた。やがて買収され、何年も積み上がったドキュメントやissue、PRがほとんど予告もなく整理される。そして新しい会社が何か商用製品を出してくるが、自分が使っていた中核機能が欠けていたりする
その懸念は理解できるが、pyxはAstralの既存ツールとは違って、戦略的に切り分けられた製品であることを強調したい。公式発表にも「pyxはAstralの戦略の実現であり、Astralのツールは今後も無料で、オープンソースで、非常に寛容なライセンスのまま永続する」とある。私たちの目標は、オープンソースツールを収益化する代わりに、別個の商業的に持続可能な製品を作ることで不安を減らすことだ
まったくもっともな懸念だと思う。それでも、Astralの評判と実績は本当に見事だ。HNでこれほど慎重な反応が見られることに驚いた。10年以上Python開発をしてきたが、Astralが何かやると聞くといつも期待してしまう
本当に価値のある機能ならpipに取り込まれていたと思う
PyTorch、CUDA、あるいはFlashAttentionやDeepSpeedのようなもののインストールが大変だという指摘には、とても共感する。Windows（そしてWSL）では、一部のパッケージがかなり古いVisual Studioのコンパイラを要求し、そのダウンロード先を面倒な手順で探さなければならないこともある。もっと良い開発体験を待っている
実際のところ、WSLはほぼLinuxと同じなので、Visual Studioコンパイラのバージョンはあまり重要ではないと思う。WSLのバイナリはすべてLinuxツールチェーンでビルドされる。WindowsでもlibcはWin10以降かなり安定している。VC++ 2015以降でビルドしたバイナリ同士ならC-ABI互換性が保たれる。例外は、特定の言語機能を古いコンパイラがサポートしていない場合や、C++オブジェクトをABIをまたいで直接受け渡そうとする場合くらいだ。そういうケースはまれだ
こういうエピソードのせいで、RailsをきっかけにRubyから完全に手を引いたことがある。Rubyの動画を見ると皆楽しそうに開発していてうらやましかったが、自分の環境では開発環境を整えるにはDigitalOceanのdropletを使うしかなく、Rails向けのコンパイルエラーでしばしば詰まった。2012年ごろにRailsブームに乗りたかったが、設定やインストールの過程はいつも悪夢のようだった。それでPythonに移った当初はうまくいっていたが、今ではAIやCUDA関連になると、むしろインストール地獄のせいで誰かのshellスクリプトに従うほうがましだと感じるレベルだ
GPU中心のワークフローでは、Pythonパッケージングはこういう方向に進むべきだと思う。特に期待している点が二つある。第一に、アクセラレータごと（たとえばCUDA/ROCm/CPUそれぞれ）に互換性検証済みのインデックスが提供され、torch/cu*のマトリクス論争がなくなること。第二に、メタデータをクライアントが問い合わせて、インストールを並列化できるようにすること。pyxがML環境における「pipの試行錯誤ループ」を減らし、ハードウェアターゲット向けビルドや予測可能なハッシュの提供まで実現するなら、環境構築にかかる時間は大幅に節約できるだろう。また、ツール自体はオープンソースのままにし、ホスティングサービスで収益を上げるモデルは、信頼構築の面でも好ましい。pyxが依存関係グラフ、逆依存関係（X→Yだと何が壊れるか？）、SBOM/署名証明のようなサプライチェーンチェックにも対応するのか気になる
かつてはOSといえばコンパイラを内蔵しているのが当たり前だった
昔Anacondaを使おうと決めた決定的な理由がまさにこういう環境だった
「そのうち競合するPythonパッケージング標準が14個できる」という冗談が出ていた。実際には14個というのはジョークで、もうとっくにそれ以上ある
Pythonパッケージングは、Pythonの中で最もZen（簡潔さやシンプルさなどのPython哲学）に反している部分だと思う
昨年9月、CharlieがMastodonでこのビジネスモデルを構想中だと明かしていた https://hachyderm.io/@charliermarsh/113103564055291456
GPU-awareなレジストリが具体的に何を意味するのか気になる。uvが自分のGPU仕様を確認して、それに合ったパッケージ群をPyxから自動で取ってきてくれるということなのか？ これが企業顧客向けのプライベートな有料レジストリだとしたら、そうしたレジストリを企業が公開インスタンスとして外部に提供することもできるのか？ つまり、自分がベンダーなら、自社パッケージ向けのPyxレジストリを有料で運営し、それを顧客向けのエントリーポイントとして使えるのか知りたい
uv pip install --torch-backend=auto torchとすると、PyTorchインデックスから自分のGPUに合ったバージョンのPyTorchを自動でインストールしてくれる。pyxはそれをさらに拡張したものだ。PyTorchだけでなく、各種ハードウェアアクセラレータごとに厳選されたインデックスを持ち、そのインデックスにはさまざまなパッケージ、バージョン、Pythonバージョン、PyTorchバージョンなどについて、ビルド済み成果物が一貫したメタデータ付きで用意される。つまりpyxを使えば、互換性や速度の面で適切なビルドを簡単に入手でき、uvクライアントも適切なpyxインデックスを自動で見つけられる（この部分はpyxを使うかどうかに関係なく基本的に実装されるが、pyxだとはるかに強力になる）。さらに、ベンダー自身が自社パッケージ向けにpyx型レジストリを運営し、それを顧客のエントリーポイントとして提供する機能はまだ正式にはサポートされていないが、具体的に関心があるなら連絡してくれれば相談できる数週間前にも言ったが、Astralはいずれ収益化戦略を打ち出すだろう。中核になるのはUvではなく、保護されたプライベートPyPIのような形だと予想している https://news.ycombinator.com/item?id=44712558
この話の要点がよく分からない。実際、Charlie Marshは昨年9月にまさにそう説明していた。エンタープライズ向けのプライベートパッケージレジストリのようなものが戦略的な例になりうると（必ずそうするという意味ではなく、戦略構想を具体的に示すための例として使っていた）。Astralはビジネスモデルについてかなり透明性が高い https://hachyderm.io/@charliermarsh/113103605702842937
「収益化」という言い方だとネガティブに聞こえるかもしれないが、彼らは本当に優れたツールを作ってきたので、もっと多くの問題を解決してほしいと望む企業が対価を払うのは当然だと思う
uvはまだ導入しておらず、今後どう動くのか見ているところだ。最近はAnacondaツールの扱いもライセンス変更のせいで見直さなければならなかったし、Qtも同様だった。また別のライセンス問題に直面することを考えると気が重い