PYX: Der nächste Schritt im Python-Packaging

 (astral.sh)
18 Punkte von GN⁺ 2025-08-14 | 4 Kommentare | Auf WhatsApp teilen
  • pyx ist eine Python-native Paket-Registry des uv-Entwicklungsteams und beschleunigt die Installation aus PyPI-, PyTorch- und privaten Quellen um bis zu das 10-Fache
  • Über den Rahmen klassischer Paket-Registries hinaus bietet sie Geschwindigkeit, Sicherheit und GPU-Erkennung und unterstützt sowohl interne Pakete als auch öffentliche Quellen wie PyPI und PyTorch
  • Sie stellt dedizierte Index-URLs bereit, mit denen sich nach Kriterien wie Paketpopularität, Erstellungszeitpunkt und bekannten Schwachstellen filtern lässt, um Sicherheit und Compliance zu stärken
  • Durch die Unterstützung aktueller, Python-spezifischer Standards und die direkte Integration mit uv sind Authentifizierung und Nutzung ohne Konfiguration möglich
  • Zentrale Probleme in Enterprise-Umgebungen wie doppelte Builds im Team, die schwierige Installation von PyTorch und CUDA, kaputte Builds oder umständliche Authentifizierung werden durch die Server-Client-Integration gelöst
  • Mit der GPU-Erkennung werden vorgebaute Versionen von PyTorch, vLLM, FlashAttention und DeepSpeed passend zur Hardware mit konsistenten Metadaten und optimaler Konfiguration bereitgestellt
  • Optimierte Artefakte und die uv-native Metadaten-API liefern im Vergleich zu anderen privaten Registries eine deutlich überlegene Leistung

Astrals Vision und Hintergrund

  • Astral ist ein Unternehmen, das hochperformante Entwickler-Tools für das Python-Ökosystem baut und vor allem für Ruff (Linter und Formatter) sowie uv (Paketmanager) bekannt ist
  • Der Anstoß zur Gründung war die Erkenntnis, dass Python zwar die beliebteste Programmiersprache der Welt ist, aber bei der Tooling-Unterstützung nicht ausreichend versorgt wird
  • Die Astral-Toolchain verzeichnet derzeit mehr als 100 Millionen Installationen pro Monat, uv verarbeitet über 500 Millionen Requests pro Tag und wächst explosionsartig
  • Das Ziel ist, Python zum produktivsten Programmier-Ökosystem zu machen; dafür will Astral über Client-Tools hinaus eine Python-Cloud aufbauen

Einführung in pyx

  • pyx ist eine Python-native Paket-Registry, die als optimiertes Backend für uv entwickelt wurde
    • Hosting interner Pakete ist möglich
    • Es kann als beschleunigendes und konfigurierbares Frontend für öffentliche Quellen wie PyPI oder den PyTorch-Index dienen
  • Wichtige Merkmale
    • Schnelle Installationsgeschwindigkeit: Optimierung von Paketinstallation und Builds
      • Bei der Installation von Paketen aus PyPI, PyTorch und internen privaten Quellen werden optimierte Artefakte und die uv-native Metadaten-API genutzt
      • Im Vergleich zu anderen privaten Registries ist sie bis zu 10-mal schneller
    • Mehr Sicherheit und bessere Compliance: Risikominimierung durch Verständnis von Abhängigkeiten und Supply Chain
      • Dedizierte Index-URLs zur Paketfilterung können erstellt werden
      • Zugriff auf Pakete lässt sich anhand von Popularität, Veröffentlichungsalter oder Schwachstellenstatus steuern
      • Reproduzierbare Builds werden serverseitig garantiert
    • Unterstützung aktueller Standards
      • Unterstützt moderne, Python-spezifische Packaging-Standards und Workflows
      • Durch die direkte Integration mit uv sind nahtlose Authentifizierung und Nutzung ohne zusätzliche Konfiguration möglich
    • GPU-bewusste Paketbereitstellung: Vereinfachung von Build und Distribution rund um CUDA und PyTorch
      • Maßgeschneiderte Prebuilds für GPU-bezogene Bibliotheken wie PyTorch, vLLM, FlashAttention und DeepSpeed
      • Hardwarebasierte optimale Konfiguration bei gleichzeitig konsistenten Metadaten

Welche Probleme gelöst werden sollen

  • Die schwierige Installation GPU-bezogener Bibliotheken wie PyTorch, CUDA, FlashAttention und DeepSpeed
  • Ressourcenverschwendung durch wiederholte Builds desselben Pakets innerhalb eines Teams
  • Build-Fehler durch Updates von setuptools
  • Umständliche Authentifizierungsprozesse bei internen Registries

Strategie der Server-Client-Integration

  • Durch die vertikale Integration von uv (Client) und pyx (Server) werden diese Probleme direkt adressiert
  • uv kann ohne pyx und pyx ohne uv verwendet werden, doch zusammen bieten sie die beste Erfahrung
  • Durch die tiefe Integration mit Open-Source-Tools wird eine Entwicklererfahrung möglich, die zuvor nicht realisierbar war

Geschäftsmodell

  • Astral-Tools wie uv, Ruff und ty bleiben dauerhaft kostenlos, Open Source und unter permissiver Lizenz
  • Stattdessen bietet Astral kostenpflichtige Hosting-Services wie pyx an, um die Nachfrage nach Infrastruktur auf der „nächsten Stufe“ zu bedienen

Aktueller Stand und weitere Pläne

  • Derzeit ist pyx mit frühen Partnern wie Ramp, Intercom und fal im Einsatz
  • Bis zum GA-Start (General Availability) wird über Open Builds ein schneller Feedback-Zyklus beibehalten
  • Interessierte Teams und Unterstützer sind aufgerufen, Kontakt aufzunehmen

Verwandte Beiträge

4 Kommentare

 
roxie 2025-08-15

Ich habe beim Lesen die ganze Zeit gedacht: Wie verdient dieses Unternehmen eigentlich Geld? Offenbar planen sie, pyx kostenpflichtig anzubieten.
 
ndrgrd 2025-08-14

„All python packaging challenges are solved“ – das ist ja eine lächerliche Aussage.
Ist das wirklich gelöst, oder hat man es nur so weit aufgeräumt, dass es irgendwie funktioniert?

Python ist eine Mainstream-Sprache, die weltweit genutzt wird, und es stimmt einfach, dass das Umfeld extrem chaotisch ist.
In den Hacker-News-Kommentaren sorgen sich manche darum, dass sich jetzt „Unternehmen“ einmischen, aber sie übersehen, dass sich niemand darum gekümmert hat, bis Unternehmen aktiv wurden, und dass die Lage deshalb so geworden ist.
 
aqqnucs 2025-08-14

Zur Info: Hier wird zitiert, was jemand in den Hacker-News-Kommentaren gesagt hat
 
GN⁺ 2025-08-14
Hacker-News-Kommentare

  • Vermutlich hilfreicher ist dieser Blogbeitrag: https://astral.sh/blog/introducing-pyx

    • Obwohl der Link die Sache klarer erklärt, verstehe ich immer noch nicht wirklich, welches Problem sie lösen wollen und wie ihre Lösung konkret funktioniert

  • Ich denke, alle Probleme beim Python-Packaging sind bereits gelöst. Die Lehre hier ist, dass es keine einzelne Lösung gibt, die perfekt zu jedem Problem passt. Sich stärker an VC-finanzierte Unternehmen zu binden oder von deren Infrastruktur abhängig zu werden, ist für die FOSS-Community immer ein großes Risiko

    • Ich habe am Anfang gehört, man solle pip verwenden. Aber es war langsam und machte oft Probleme. Also bin ich zu virtualenv gewechselt, aber das hat nur einen Teil des Problems gelöst. Danach habe ich conda benutzt; das funktionierte manchmal gut, hat aber mein Shell-Profil durcheinandergebracht, und oft gab es Versionskonflikte bei Paketen. Dann wurde mir pipenv empfohlen; anfangs war es gut, aber nachdem die Entwicklung vernachlässigt wurde und Leute wechselten, ging es in neueren Versionen oft kaputt. Danach wurde mir wieder poetry empfohlen, aber das war zu langsam, um es zu benutzen. Also bin ich zurück zu pip und dem eingebauten venv, bin dort aber wieder auf die früheren Probleme gestoßen, und es hatte noch weniger Funktionen. Dann bin ich zu uv gewechselt, und das funktionierte immerhin ordentlich. Aber die Abhängigkeiten, die ich brauche, werden je nach Betriebssystem und GPU unterschiedlich gebaut und paketiert, sodass meine Kollegen dieses Projekt nicht einmal auf ihren Laptops installieren können. Wie beruhigend, dass die Python-Packaging-Probleme alle schon „gelöst“ sind

    • Die Behauptung, „alle Python-Packaging-Probleme sind bereits gelöst“, ist ehrlich gesagt entweder uninformiert oder schlicht ignorant. Python hat immer noch keine verlässliche Möglichkeit, native Abhängigkeiten plattformübergreifend zu handhaben. pip und setuptools sollten nicht das Endstadium dieses Ökosystems sein

    • Ich verstehe die Sorge, aber seit ich uv benutze, spare ich enorm viel Zeit, deshalb werde ich es weiter nutzen, bis die Schattenseiten von VC-Kapital alles komplett ruinieren. Bis dahin hoffe ich, dass sich die Community auf eine Richtung einigen kann

    • Ich habe die letzten drei Stunden damit verbracht, Python und Debian gegeneinander antreten zu lassen, und mein Zorn auf das Python-Ökosystem ist hochgekocht. Da ist gar nichts gelöst. Unter Debian wird praktisch nur die Nutzung von venv empfohlen, aber Pakete, die in venv installiert sind, werden von Tools wie cmake leicht nicht gefunden. Dann gibt es auch noch apt-get-Pakete, die manche Tools finden und andere wieder nicht. Die Paketnamen sind ebenfalls inkonsistent. Meine Konsole hat mir pipx empfohlen, aber die Nutzungserfahrung ist ähnlich. Außerdem gibt es immer noch Altlasten aus der Zeit von Python 2 vs. 3, sodass die Paketauflösung oft schon daran scheitert, ob eine Versionsnummer im Namen steckt oder nicht. Selbst wenn ich nicht weiß, was c++headerparser ist, bin ich am Ende überzeugt, dass es richtig ist, Python einfach aus dem Build-Tree zu entfernen und es der Geschichte zu überlassen

    • Sind Sie vielleicht neu hier? Ich würde empfehlen, erst einmal etwas von diesem Kool-Aid zu trinken. Das „MongoDB“-Logo auf dem Glas können Sie ignorieren. Das ist alt

  • Ich habe zu oft schlechte Erfahrungen damit gemacht, Open-Source-Produkten zu vertrauen. Solche Versprechen habe ich schon unzählige Male gehört. Irgendwann kommt eine Übernahme, und über Jahre angesammelte Dokumentation, Issues und PRs werden fast ohne Vorwarnung bereinigt. Dann bringt das neue Unternehmen irgendein kommerzielles Produkt heraus, aber zentrale Funktionen, die ich genutzt habe, fehlen plötzlich

    • Ich verstehe diese Sorge, möchte aber betonen, dass pyx strategisch von Astrals bestehendem Tooling getrennt ist. In der offiziellen Ankündigung heißt es auch: „pyx ist die Umsetzung von Astrals Strategie, und Astrals Tools bleiben auch künftig für immer kostenlos, Open Source und unter sehr großzügigen Lizenzen verfügbar.“ Unser Ziel ist, die Sorge zu mindern, indem wir statt der Monetarisierung von Open-Source-Tools ein separates, kommerziell tragfähiges Produkt schaffen

    • Das ist eine völlig nachvollziehbare Sorge. Trotzdem finde ich Astrals Ruf und bisherige Bilanz wirklich beeindruckend. Ich war überrascht, auf HN so eine vorsichtige Reaktion zu sehen. Ich entwickle seit über zehn Jahren mit Python, und wenn Astral etwas macht, werde ich immer aufmerksam

    • Wenn es wirklich wertvolle Funktionen wären, wären sie wohl in pip aufgegangen

  • Der Hinweis, dass sich Dinge wie PyTorch, CUDA oder FlashAttention, DeepSpeed schwer installieren lassen, trifft bei mir voll zu. Unter Windows (und WSL) gibt es auch das Problem, dass manche Pakete Compiler aus uralten Visual-Studio-Versionen verlangen, sodass man mühsam Downloadpfade von Hand suchen muss. Ich warte auf eine bessere Developer Experience

    • Eigentlich ist WSL fast dasselbe wie Linux, deshalb glaube ich nicht, dass die Visual-Studio-Compiler-Version dort besonders wichtig ist. WSL-Binaries werden alle mit Linux-Toolchains gebaut. Auch unter Windows ist libc seit Win10 sehr stabil. Zwischen Binärdateien, die mit VC++ 2015 oder neuer gebaut wurden, bleibt die C-ABI-Kompatibilität erhalten. Nur in Ausnahmen braucht man einen alten Compiler, etwa wenn eine bestimmte Spracheigenschaft dort noch nicht unterstützt wurde oder wenn man C++-Objekte direkt über ABI-Grenzen hinweg übergeben will. Solche Fälle sind selten

    • Wegen genau solcher Erlebnisse habe ich Ruby trotz Rails irgendwann komplett aufgegeben. Wenn man Ruby-Videos schaut, wirken alle glücklich beim Entwickeln, und das hat mich neidisch gemacht, aber in meiner Umgebung musste ich für das Aufsetzen der Entwicklungsumgebung einen DigitalOcean-Droplet nutzen, und die Rails-Kompilierung ist oft mit Fehlern abgestürzt. Um 2012 herum wollte ich beim Rails-Hype mitmachen, aber Konfiguration und Installation waren immer ein Albtraum. Deshalb bin ich zu Python gewechselt, und anfangs lief es gut, aber heutzutage ist es bei AI- oder CUDA-Themen fast schon so, dass man wegen der Installationshölle besser einfach irgendein Shell-Skript von jemand anderem übernimmt

    • Ich denke, für GPU-zentrierte Workflows sollte Python-Packaging in genau diese Richtung gehen. Zwei Dinge finde ich besonders spannend. Erstens, dass es pro Accelerator (z. B. CUDA/ROCm/CPU jeweils) validierte Indizes gibt, sodass die Diskussionen um die torch/cu*-Matrix verschwinden. Zweitens, dass Clients Metadaten abfragen können, um Installationen zu parallelisieren. Wenn pyx in ML-Umgebungen die „pip-Versuch-und-Irrtum-Schleife“ reduziert und zusätzlich hardwarezielspezifische Builds sowie vorhersagbare Hashes liefert, spart das enorm viel Zeit beim Aufsetzen von Umgebungen. Außerdem ist es vertrauensfördernd, das Tool selbst Open Source zu lassen und Einnahmen über einen Hosting-Service zu erzielen. Ich frage mich, ob pyx auch Checks der Supply Chain wie Abhängigkeitsgraphen, Reverse Dependencies (was geht kaputt, wenn X→Y?), SBOMs und Signaturnachweise unterstützen wird

    • Es gab einmal eine Zeit, in der es selbstverständlich war, dass ein Betriebssystem einen Compiler mitbringt

    • Genau aus solchen Gründen war das damals mein ausschlaggebender Grund, Anaconda zu verwenden

  • Jemand macht den Witz, dass es „bald 14 konkurrierende Python-Packaging-Standards geben wird“. In Wirklichkeit sind 14 natürlich ein Scherz, denn es gibt schon seit Langem mehr als das

    • Es gibt im Python-Packaging tatsächlich sehr viele Standards, aber ich denke, die meisten aus den letzten gut zehn Jahren konkurrieren nicht miteinander. Eher sind sie „das Ergebnis einer allmählichen Anhäufung von Funktionen, die als brauchbar gelten“. Das liegt daran, dass die Standardisierung des Python-Packaging ein gesunder, konsensbasierter Prozess ist und kein autoritärer. Wäre sie autoritär gewesen, hätte Python wohl kaum den Erfolg, den es heute hat (zur Einordnung: Ich habe mindestens fünf PEPs vorgeschlagen)

  • Ich finde, Python-Packaging ist der Teil von Python, der dem Zen von Python am stärksten widerspricht

  • Im vergangenen September hat Charlie auf Mastodon gesagt, dass er an diesem Geschäftsmodell arbeitet: https://hachyderm.io/@charliermarsh/113103564055291456

  • Ich frage mich, was ein GPU-aware Registry konkret bedeutet. Heißt das, uv prüft meine GPU-Spezifikationen und zieht dann automatisch aus Pyx das passende Paketset? Wenn das eine private, kostenpflichtige Registry für Unternehmenskunden ist, könnte ein Unternehmen so eine Registry dann auch als öffentliche Instanz nach außen anbieten? Anders gesagt: Wenn ich ein Vendor wäre, könnte ich dann eine kostenpflichtige Pyx-Registry für meine Pakete betreiben und sie meinen Kunden als Entry Point bereitstellen?

    • uv unterstützt bereits eine Grundform dieser Idee. Zum Beispiel installiert uv pip install --torch-backend=auto torch automatisch die Version von PyTorch aus dem PyTorch-Index, die zu meiner GPU passt. pyx ist eine weiter ausgebaute Form davon. Es hat nicht nur für PyTorch, sondern für verschiedene Hardware-Beschleuniger kuratierte Indizes, in denen Build-Artefakte für unterschiedliche Pakete, Versionen, Python-Versionen, PyTorch-Versionen usw. zusammen mit konsistenten Metadaten bereitliegen. Mit pyx kann man also leicht einen Build bekommen, der bei Kompatibilität und Geschwindigkeit gut passt, und der uv-Client kann passende pyx-Indizes automatisch finden (dieser Teil wird grundsätzlich umgesetzt, egal ob man pyx nutzt oder nicht; mit pyx ist es nur deutlich leistungsfähiger). Außerdem wird die Funktion, dass ein Vendor selbst eine pyx-artige Registry für eigene Pakete betreibt und sie Kunden als Einstiegspunkt anbietet, offiziell noch nicht unterstützt, aber wenn konkretes Interesse besteht, kann man sich melden und darüber sprechen

  • Ich habe es vor ein paar Wochen schon gesagt: Irgendwann wird Astral eine Monetarisierungsstrategie fahren. Der Kern wird nicht uv sein, sondern vermutlich etwas wie ein geschütztes privates PyPI: https://news.ycombinator.com/item?id=44712558

    • Ich verstehe nicht ganz, worauf diese Aussage hinauswill. Tatsächlich hat Charlie Marsh das schon im letzten September direkt so erklärt – etwa, dass eine private Paket-Registry für Unternehmen ein strategisches Beispiel sein könnte (nicht unbedingt genau so, sondern als konkrete Veranschaulichung der Strategie). Astral ist bei seinem Geschäftsmodell sehr transparent: https://hachyderm.io/@charliermarsh/113103605702842937

    • „Monetarisierung“ kann negativ klingen, aber sie haben wirklich hervorragende Tools gebaut, und Unternehmen, die möchten, dass noch viel mehr Probleme gelöst werden, werden dafür gern bezahlen

    • Ich habe uv noch nicht eingeführt und beobachte erst einmal, welchen Weg es einschlägt. In letzter Zeit mussten wir den Einsatz von Anaconda-Tools wegen Lizenzänderungen ohnehin neu bewerten, bei Qt war es ähnlich. Die Aussicht, noch einmal in Lizenzprobleme zu geraten, ist belastend