Rye: Ein Python-Erlebnis ohne Aufwand

• Rye war ein Projekt- und Paketverwaltungswerkzeug, das Python-Installationen, pyproject.toml-Projekte, Abhängigkeiten, virtuelle Umgebungen und die Installation globaler Tools an einem Ort verwalten sollte
• Die Entwicklung wurde inzwischen eingestellt, und stattdessen wird die Nutzung des Nachfolgeprojekts uv empfohlen, das von denselben Maintainern entwickelt wird
• Bestehende Nutzer können mithilfe des uv migration guide migrieren; Rye kann weiterhin bezogen werden, aber es sind keine weiteren Updates geplant
• Das Ende der Updates umfasst auch Sicherheitsupdates, daher sollte für neue Projekte oder langfristige Wartungsumgebungen ein Wechsel zu uv in Betracht gezogen werden
• Die integrierte Python-Erfahrung, die Rye anstrebte, umfasste auch komplexe Projekte und Monorepos, doch der Schwerpunkt der Wartung ist zu uv gewandert

---

Der aktuelle Status von Rye

• Eingestellte Entwicklung und Empfehlung für uv

  • Allen Nutzern wird die Verwendung von uv empfohlen
  • uv ist ein von denselben Maintainern entwickeltes Nachfolgeprojekt
  • uv wird aktiv gepflegt und ist deutlich weiter verbreitet als Rye
  • Bestehende Rye-Nutzer können den uv migration guide konsultieren
  • Rye kann weiterhin verwendet werden, aber es sind keine weiteren Updates geplant
  • Auch Sicherheitsupdates sind nicht geplant

Welche Funktionen Rye bereitstellte

• Rye ist eine Projekt- und Paketverwaltungslösung für Python
• Es wurde mit dem Ziel entwickelt, ein One-Stop-Tool für Python-Nutzer zu sein
• Innerhalb einer integrierten Nutzungserfahrung deckt es folgende Aufgaben ab
  • Verwaltung von Python-Installationen
  • Projektverwaltung auf Basis von pyproject.toml
  • Abhängigkeitsverwaltung
  • Verwaltung virtueller Umgebungen
  • Installation globaler Tools
• Es wurde dafür konzipiert, komplexe Projekte und Monorepos zu handhaben
• Ein Einführungsvideo ist unter Watch an introduction verfügbar

[lum7671]

Es ist schon eine Weile her, aber nachdem ich dies und das ausprobiert habe, verwende ich
Introduction - PDM
.

Dann sollte ich wohl auch Rye einmal ausprobieren.

[GN⁺]

Hacker-News-Kommentare

• Ein großer Teil der zentralen Packaging-Entwicklung findet inzwischen bei uv statt, und Rye nutzt uv intern. Wenn uv besser wird, wird Rye also mit besser.
  Zum Beispiel wurde uv kürzlich um universelle Dependency Resolution erweitert, sodass man eine gesperrte requirements.txt mit einem einzigen Resolution-Ergebnis erstellen kann, das nicht nur auf dem aktuell laufenden System, sondern auf allen Plattformen und Betriebssystemen funktioniert. Das aktuelle Rye unterstützt das ebenfalls.
  https://github.com/astral-sh/uv
  Ich arbeite an Rye und uv; wenn es Fragen gibt, kann ich sie beantworten.

  • Mich interessiert, ob die universelle Dependency Resolution von Rye/uv auch mit PyTorch richtig funktioniert oder ob sie auf dieselben Probleme stößt wie Poetry.
    https://github.com/python-poetry/poetry/issues/6409
    https://news.ycombinator.com/item?id=39257501
  • Mich würde interessieren, ob man die Arbeit oder Pläne für plattformübergreifende Lockfiles irgendwo verfolgen kann.
    Das ist einer der Gründe, warum mein Team beim Umstieg zögert. Da wir ML-Arbeit machen, wäre bei einem PyTorch-basierten Projekt der gewünschte Zustand zum Beispiel, alle Dependencies in pyproject.toml zu haben und von einer AArch64-Mac- oder AMD64-Windows-Workstation aus Lockfiles für folgende Plattformkonfigurationen erzeugen zu können: Mac mit Standard-MPS-PyTorch, Windows mit CUDA-PyTorch, AArch64 Linux mit CPU-PyTorch, AMD64 Linux mit CPU-PyTorch, AMD64 Linux mit CUDA-PyTorch.
    Danke für Ruff; wir sind sowohl mit dem Linting als auch mit der Formatierung sehr zufrieden.
  • Großartige Arbeit. Früher musste ich gelegentlich auf einem neuen Rechner die Arbeitsumgebung für ein Projekt einrichten, und pyenv+venv+pip war immer schmerzhaft. Inzwischen bin ich zu Rye gewechselt.
    Jetzt reicht: Rye installieren, von GitHub holen, rye sync eingeben, fertig.
  • Wenn ihr sowohl uv als auch rye betreut, frage ich mich, warum ihr beide gleichzeitig pflegt. Um die Verwirrung durch Fragmentierung und Entscheidungsdruck zu vermeiden, wäre es vielleicht besser, rye jetzt einzustellen.
  • Viele Unternehmen, denen vorhersehbare und performante Builds wichtig sind, wechseln gerade, und dabei braucht man häufig SBOM-Erzeugung, etwa um sie in Tools wie guac einzuspeisen.
    https://guac.sh/
    https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
    Dank der kürzlich hinzugefügten Funktion zum Aufheben fester Dependency-Pinnings kann man während der Entwicklung Kompatibilität fördern und für Reproduzierbarkeit eine genaue, explizite requirements.txt erzeugen. Dadurch werden Vulnerability Management und der SBOM-Schritt deutlich einfacher als mit Tools wie Poetry.
    Aus ähnlichen Gründen nutze ich https://hatch.pypa.io/latest/why/, und mir gefällt auch, dass es gut mit uv zusammenspielt.

• Was mich an Rye abgeschreckt hat, ist, dass es stark zur Nutzung eines nicht standardmäßigen Python-Builds rät.
  Auf der Philosophie-Seite (https://rye.astral.sh/philosophy/) wird erklärt, dass die CPython-Builds von python.org völlig unzureichend seien, je nach Plattform nur .msi-Installer oder nur Tarballs bereitstünden und die verschiedenen Python-Distributionen stark auseinanderliefen, was im nachgelagerten Ökosystem allerlei Probleme verursache. Deshalb verwendet das Projekt die Standalone-Builds von indygreg und hofft, dass es irgendwann gut gepflegte und vertrauenswürdige Python-Builds gibt, die das heutige Durcheinander ersetzen.
  Informationen zu diesen indygreg-Builds gibt es unter https://gregoryszorc.com/docs/python-build-standalone/main/, und man kann auch ein anderes Python auswählen: https://rye.astral.sh/guide/toolchains/
  Allerdings bin ich den dort beschriebenen Problemen kaum je begegnet. Offizielle Python-Builds von python.org haben funktioniert, normales über den Paketmanager der Distribution installiertes Python hat funktioniert, und Python in offiziellen Docker-Container-Images hat ebenfalls funktioniert.
  Diese speziellen Builds mögen gut funktionieren, aber wegen der Nicht-Standardmäßigkeit zögere ich. Es gibt sogar eine Liste von Laufzeit-Besonderheiten; ich verstehe nicht, warum man Besonderheiten hinzufügen sollte, wo es kein Problem gibt. Dass die Rye-Philosophie so offensiv für diese Builds eintritt, macht es für mich weniger attraktiv als Alternativen, die standardmäßig das bereits im Betriebssystem vorhandene Python verwenden.

  • Vermutlich ist so eine Situation gemeint: Man arbeitet in einem Unternehmen, das etwas wie ein altes CentOS nutzt, der System-Paketmanager bietet nichts Neueres als Python 3.6 an, und die offiziellen Binärdateien von python.org geben beim Start einen unentzifferbaren Fehler zur glibc-Version aus.
    Python aus dem Quellcode zu bauen braucht neue System-Dependencies und dauert lange, und am Ende erhält man noch unverständlichere Fehler wegen fehlender Header-Dateien. Sucht man nach diesem Fehler, findet man ein ./configure-Flag, das ein Problem umgeht, das Upstream-GCC 2017 behoben hat, und irgendwie klappt es dann doch.
    Wenn man solche dreifachen Fehler oder manylinux-Build-Umgebungen nie erlebt hat, hat man eine ganze Welt des Schmerzes vermieden. Dasselbe gilt für Windows-Installationsskripting oder Punkte wie „Einschränkung der verfügbaren CPU-Instruktionen“ auf jener Seite.
  • Bei Python-Builds, Packaging und Distribution gibt es zwei Extreme. Das eine ist der Königsweg, das andere ein Korridor mit tausend Klingen. Wenn einem der Vorschlag für ein portables Python nicht einleuchtet, hatte man Glück – und ist die ganze Zeit auf dem Königsweg geblieben.

• Python-Quellcode wird regelmäßig heruntergeladen, mit standardmäßigen Produktionsoptimierungen kompiliert und anschließend unter /use/local/python${version} installiert; seit Python 3.7 im Jahr 2018 erschienen ist, funktioniert das äußerst konsistent.
  Nach meiner Erfahrung sind diese Befehle so stabil und konsistent, dass man sie problemlos automatisieren könnte. Ich frage mich, wo der Autor genau das Problem sieht oder was der grundlegende Einwand ist.

  • Mit „die CPython-Builds von python.org sind völlig ungeeignet“ ist vermutlich gemeint, dass es für Security-Releases älterer Python-Versionen keine macOS-/Windows-Binaries gibt.
    Für Python 3.10.14 etwa kann man keine Installationsdatei herunterladen; der letzte Windows-Installer ist Python 3.10.11 vom 5. April 2023.
  • Stimme zu. Man sollte die PSF unterstützen; eine neue „richtige Methode“ zu propagieren, ist eine seltsame Position.

• Ich mag Rye. Es tut genau das, was es verspricht, macht den gesamten Ablauf rund um venv, Python-Versionen und Packaging tatsächlich angenehm und wirkt für Leute, die mit offiziellen Python-Nutzungsweisen wie pyproject.toml vertraut sind, nahezu transparent.
  Außerdem lässt es Python wie Cargo wirken, und Cargo ist ebenfalls ein sehr angenehmes Tool.

  • Wenn man wie ich Poetry-artige Ansätze ignoriert und bei pip-tools geblieben ist, ist uv, das Rye intern verwendet, ein direkt ersetzbares Werkzeug.
    Persönlich halte ich pip-tools für deutlich besser designt als Poetry oder Pipenv. Es war sowohl zu pip als auch zu virtualenv orthogonal, und beides sind ohnehin seit Langem etablierte Workflows in Python. Rye kann man als Beispiel dafür sehen, dass ein iterativ verbesserter, standardkonformer Ansatz gewinnt.
    Neben dem Geschwindigkeitsschub durch Rust gefällt mir, dass es sinnvolle Defaults dafür gibt, wo virtuelle Umgebungen liegen sollen (.venv) und wie mehrere Python-Versionen installiert werden. Das wirkt klein, aber nachdem Wheels die numpy-Installationsprobleme gelöst hatten, waren solche vernünftigen Defaults und eingebaute pip-tools im Grunde alles, was noch fehlte. In diesem Sinne frage ich mich auch, welche Existenzberechtigung Anaconda nach dem Aufkommen binärer Wheels noch hatte.
  • Ich hatte mit Python angefangen, weil ich gehört hatte, dass es für alles genau einen Weg gebe, aber die Erfahrung bei Installation und Environment-Management war ein Chaos.
    Schön zu hören, dass es inzwischen besser wird.
  • Wenn es „Python wie Cargo wirken lässt“, bin ich sofort überzeugt. Poetry hat einen ganzen Tag gebraucht und konnte die Abhängigkeiten trotzdem nicht auflösen, daher hatte ich gerade überlegt, pixi auszuprobieren.
    Es scheint mehr Python-Paketmanager zu geben als Google-Chat-Apps.
  • Ich frage mich, was mit „macht es tatsächlich angenehm“ gemeint ist. Ist das zu schwer zusammenzufassen? Bei Anaconda oder Poetry konnte ich in Sachen User Experience kaum etwas finden, das sich wie eine besondere, bewusst getroffene Entscheidung anfühlte.
    Und was Kuratierung angeht, wirkt der Vorschlag, einer kleinen Organisation mehr zu vertrauen als einer größeren und älteren, schwer überzeugend. Anders gesagt: Ich frage mich, was genau versprochen wird. Was ich herauslesen kann, ist ungefähr „ein guter Paketmanager ist gut und schnell und gut“; eine Vergleichs- oder Philosophie-Seite wäre hilfreich.

• Der Zynismus auf HN überrascht mich manchmal.
  Ich mag Rye. Nachdem ich Paketmanager anderer Sprachen wie Cargo oder Hex benutzt hatte, fand ich es immer schade, dass Python kein ähnliches System hat; Rye hat diesen Bedarf für mich vollständig gedeckt. Wenn man nicht mehrere Tools installieren möchte, um venv, Python-Versionen und Projektabhängigkeiten zu verwalten, ist es wirklich schön, dass Rye alles in einem erledigt.

  • Ich frage mich, ob du conda ausprobiert hast. Wie schneidet Rye im Vergleich zu conda ab?
    Bei Rye habe ich noch kein Gefühl dafür, aber conda kann venv, Python-Versionen und Projektabhängigkeiten ebenfalls gut verwalten.
  • Stimme zu. Rye funktioniert bei mir gut. Ich wollte Cargo für Python, und aus meiner Sicht hat Rye das bisher erreicht.

• Einen neuen Python-Dependency-Manager zu entdecken fühlt sich an, als würde man zufällig auf ein neues JavaScript-Framework stoßen.

  • Meine Philosophie ist einfach: Wenn es ein auslieferbares Programm sein muss, nehme ich einfach Go; wenn es keine Ports oder Ähnliches braucht, nehme ich Docker; und wenn mir die IT-Abteilung oder jemand anderes einen Rechner mit dem im Unternehmen überall genutzten Betriebssystem und der passenden Python-Version hinstellt, dann reicht venv.
    Wenn man Ports anfassen muss, ein Programm ausliefern soll oder eine Bibliothek von C oder Betriebssystemkomponenten abhängt, ist es besser, Beratungsarbeit anzunehmen, bei der man nach der Bezahlung weder die Codebasis pflegen noch Verantwortung übernehmen muss.
  • Genau. Docker hat das Problem des Deployments und Ausführens von Python-Programmen schon vor etwa zehn Jahren gelöst.
    Heutzutage kann man in Docker auch CUDA und PyTorch ausführen. Wenn in solchen Threads jemand sagt: „Nimm einfach Docker“, lautet die übliche Antwort oft: „Ich will Docker nicht lernen“; dabei braucht man selbst ohne jede Docker-Erfahrung vielleicht 10 Minuten, um einen Python-Container zu starten.
  • Stimmt. Aber anders als Dinge wie Poetry ist dieses hier tatsächlich gut.
  • Es ist wirklich schlimm. Aus Nutzersicht ist es frustrierend, dass es nach all diesen Jahren immer noch keinen Standard gibt.

• pixi(https://pixi.sh/latest/) ist gut. Man kann die Python-Version pinnen und Pakete aus conda und PyPI installieren; es ist in Rust geschrieben.

  • Sieht interessant aus, aber es fühlt sich schwierig an, ernsthaft in noch ein weiteres Ökosystem zu investieren. Dass man es per curl holen und in bash pipen soll und anschließend eval auf die Ausgabe eines beliebigen Befehls ausführen soll, schreckt mich ab.
  • Danke für den Link. Ich frage mich, ob es schneller als conda ist.
  • pixi ist hervorragend. Wenn man conda nutzt, kann pixi als conda-Ersatz dienen, der Environments an Git-/Projektverzeichnisse bindet, ähnlich wie devbox/devenv/flox.
    Der Hintergrund ist etwas komplex. Es gab conda von der Firma Anaconda, geschrieben in Python, und das Open-Source-Ökosystem conda-forge ist ein conda-Channel mit CI-Build-Bots. Später entstand unter demselben conda-forge-Dach mamba, in C++ geschrieben, als Ersatz für conda; es ist ein echter Drop-in-Ersatz in dem Sinne, dass alias conda=mamba funktionieren sollte. Inzwischen verwendet auch conda libmamba als Solver, um schneller zu werden.
    Danach hat der Autor von mamba das Ganze als pixi ausgegliedert und in Rust neu geschrieben, mit einer anderen Philosophie für den Ort von Environments und ihre Aktivierung, aber es bleibt vollständig kompatibel mit conda-Environments.

conda hat die Installation von PyPI-Paketen über pip immer unterstützt, etwa wenn sie nicht in den conda-Channels vorhanden waren; pixi unterstützt PyPI-Pakete über uv. Deshalb ist pixi schnell. Laut Blogbeitrag gibt es auch andere Optimierungen, die es deutlich schneller als mamba machen
Wenn man Pakete verwendet, die nicht reines Python sind, ist die conda-Familie die richtige Wahl. Die Wahl des Paketmanagers (conda/mamba/pixi) ist zweitrangig
Das Problem bei PyPI ist, dass es zu wenig Gatekeeping gibt. Dazu kommt, dass eine standardisierte Methode fehlt, Pakete, die nicht reines Python sind, zu paketieren. Dadurch können Umgebungen leaken oder, insbesondere wenn nur Source verteilt wird und dann in setup.py seltsame Dinge passieren, bis hin zum Bootstrapping der Umgebung inklusive Compiler, wird es nicht reproduzierbar
Auf conda-Seite betreibt der conda-forge-Channel eine ziemlich gute Qualitätskontrolle. Es werden Constraints, Lizenzen, fehlende Lizenzdateien in PyPI-Distributionen, Umgebungsisolation usw. geprüft. Perfekt ist es natürlich nicht, weil Maintainer einen offiziellen Bot verwenden können, der PyPI-Änderungen mit falschen Versions-Constraints automatisch merged
Das Problem, das derzeit kein Tool löst, ist PyPI-zentriert. Man muss mit Paketen umgehen, die es nicht in conda gibt, und Paket-Releases müssen faktisch zuerst auf PyPI veröffentlicht werden
Selbst wenn man Pakete, die nur auf PyPI existieren, über conda installiert, können einige ihrer Abhängigkeiten in conda vorhanden sein. Meines Wissens nutzt kein Paketmanager conda-Pakete, um Abhängigkeiten von PyPI-Paketen zu erfüllen. Man kann zwar manuell conda-Pakete hinzufügen, um die Abhängigkeiten passend zu machen, riskiert aber, dass die korrekten Versions-Constraints nicht angewendet werden
Auch wenn man Open-Source-Python-Pakete schreibt, muss oder sollte man meist zuerst auf PyPI releasen, selbst wenn die Konfiguration nur von conda-Channels abhängt. Denn Releases im conda-forge-Channel setzen faktisch voraus, dass das Paket auf PyPI existiert. Deshalb kann Rye auch für Leute wie mich weiterhin nützlich sein und ist einen Blick wert

• Bemerkenswert ist, dass die Leute hinter uv (https://astral.sh/blog/uv) die Leitung dieses Armin-Projekts übernommen haben
• Auf der Einführungsseite steht: „Rye is still a very experimental tool, but this guide is here to help you get started.“
  Ich finde dieses Projekt sehr vielversprechend, werde aber warten, bis es einen reiferen Stand erreicht hat. Da ich alles andere vom Astral-Team mag, sind meine Erwartungen hoch
• Wir verwenden rye bei der Entwicklung der openai-python-Bibliothek, und es war wirklich gut
• Rye sieht gut aus, und Poetry habe ich auch recht gerne genutzt, aber die Qualität der Standard-Tools von Go weiß ich wirklich zu schätzen
  Jedes Mal, wenn ich ein Python-Projekt starte, fühlt es sich so an, als müsste ich den aktuellen Stand von Abhängigkeits- und Virtual-Environment-Management neu lernen