Uv – ultraschnelles Python-Packaging-Tool, implementiert in Rust

• uv ist ein ultraschneller Python-Paket-Installer und Resolver, der in Rust geschrieben wurde und dafür entwickelt wurde, pip- und pip-tools-Workflows zu ersetzen
• uv ist ein Meilenstein auf dem Weg zu „Cargo for Python“: ein schneller, zuverlässiger und einfach zu bedienender umfassender Python-Projekt- und Paketmanager
• Geplant ist, die Betreuung von Rye zu übernehmen, einem von Armin Ronacher experimentell entwickelten Python-Packaging-Tool, und uv zu einem einheitlichen Nachfolgeprojekt auszubauen

Besessener Fokus auf Performance

• uv ist ohne Caching 8- bis 10-mal schneller als pip und pip-tools, mit Cache sogar 80- bis 115-mal schneller.
• Es verwendet einen globalen Modul-Cache, lädt Abhängigkeiten nicht erneut herunter und baut sie nicht neu, und minimiert auf unterstützten Dateisystemen den Speicherplatzbedarf durch Copy-on-Write und Hardlinks.

Für einfache Einführung optimiert

• Die erste Version von uv unterstützt die APIs von pip und pip-tools und kann in bestehenden Projekten ohne Konfigurationsänderungen verwendet werden.
• uv wird als einzelnes statisches Binary bereitgestellt und kann pip, pip-tools und virtualenv ersetzen.
• Es kann unabhängig von Python selbst installiert werden, ohne dass pip-Installationen je nach Python-Version verwaltet werden müssen.

„Cargo for Python“: uv und Rye

• uv ist ein Zwischenmeilenstein auf dem Weg zu einem schnellen, zuverlässigen und einfach zu bedienenden integrierten Python-Paket- und Projektmanager.
• Ziel für uv ist ein einzelnes Binary, das nicht nur pip, pip-tools und virtualenv, sondern auch pipx, tox, poetry, pyenv, ruff und mehr umfasst.

API-Kompatibilität

• Statt pip install kann uv pip install verwendet werden, um Python-Abhängigkeiten über die Kommandozeile, aus Requirements-Dateien oder aus pyproject.toml zu installieren.
• Statt pip-compile kann uv pip compile verwendet werden, um eine gesperrte requirements.txt zu erzeugen.
• Statt pip-sync kann uv pip sync verwendet werden, um eine gesperrte requirements.txt mit einer virtuellen Umgebung zu synchronisieren.

Roadmap

• Nach diesem Release soll zunächst der Nutzer-Support priorisiert und an Verbesserungen bei Kompatibilität, Performance und Stabilität gearbeitet werden.
• Danach ist das Ziel, uv zu einem vollständigen Python-Projekt- und Paketmanager auszubauen.

Dank

• Allen, die direkt oder indirekt zur Entwicklung von uv beigetragen haben, wird gedankt.
• Besonderer Dank gilt Jacob Finkelman und Matthieu Pizenberg, deren PubGrub als grundlegender Versions-Resolver in uv verwendet wird.

Meinung von GN⁺

• uv ist ein innovatives Tool, das Python-Entwicklern eine deutlich höhere Performance als bestehende pip-Werkzeuge bietet und die Zeit für das Aufsetzen von Projekten erheblich verkürzen kann.
• Da es in Rust geschrieben ist, spiegelt es einen neuen Trend im Python-Ökosystem wider, der Performance und Stabilität in den Vordergrund stellt, was das Entwicklererlebnis deutlich verbessern dürfte.
• Die Entwicklung von uv zielt auf eine Vereinheitlichung von Python-Packaging- und Projektmanagement-Tools ab, was Entwicklern effizienteres und konsistenteres Arbeiten ermöglichen dürfte.

[kyunghoon]

Die Geschwindigkeit ist wirklich enorm;;

[ajh508]

Es wäre schön, wenn es erweitert würde und conda ersetzen könnte.

[GN⁺]

Hacker-News-Kommentare

• Zweifel an einem VC-finanzierten pip-and-more

  • Schwer nachzuvollziehen, wie ein durch Venture Capital unterstütztes pip-and-more Geld verdienen soll, wenn der kostenlose Geldautomat irgendwann nicht mehr funktioniert.

• Frage dazu, dass uv keine plattformunabhängigen Lockfiles erzeugt

  • Im Unterschied zu Poetry oder PDM erzeugt uv keine plattformunabhängigen Lockfiles; dieser Ansatz wirke abhängig von Requirements-Dateien und passe daher nicht wirklich zum Ziel, ein „Cargo für Python“ zu sein.

• Positive Einschätzung der Unterstützung alternativer Strategien zur Abhängigkeitsauflösung in uv

  • uv folgt standardmäßig der üblichen Python-Strategie zur Abhängigkeitsauflösung, bei der die neuesten kompatiblen Paketversionen bevorzugt werden, bietet mit der Option --resolution=lowest aber auch die Möglichkeit, mit den niedrigsten kompatiblen Versionen zu testen.
  • Dass uv über den Parameter --python-version Lösungen auch für andere Python-Versionen als die aktuell installierte erzeugen kann, wird als großartig bewertet.

• Frage nach der Komplexität des Python-Paketsystems

  • Wenn zu den Grundsätzen des Python-Interpreters gehört, dass es „einen offensichtlichen Weg“ geben sollte, stellt sich die Frage, wie diese Paketierungslandschaft so komplex werden konnte.

• Interessanter Aspekt daran, dass uv pubgrub-rs verwendet

  • Dass uv pubgrub-rs verwendet, also eine Rust-Implementierung des ursprünglich für die Sprache Dart geschriebenen Versionsauflösungsalgorithmus pubgrub, wird als spannendes Beispiel dafür gesehen, wie sich Inspiration zwischen Sprachen fortsetzt.

• Erwähnung einer Vorhersage zur Richtung des Astral-Teams

  • Es wird erwähnt, dass schon vor 11 Tagen vorhergesagt wurde, das Astral-Team werde die Funktionen von ruff so ausbauen, dass es alles abdeckt, was Python-Entwickler brauchen.

• Persönliche Erfahrung mit der Geschwindigkeit von pip

  • pip sei meistens schnell, werde aber langsam, wenn viele Daten heruntergeladen oder native Bibliotheken kompiliert werden müssen. conda hingegen sei sehr langsam, sogar auf leistungsstarker Hardware.

• Skeptische Sicht auf einen weiteren neuen Python-Paketmanager

  • Wieder ein neuer Python-Paketmanager, aber wenn er pip tatsächlich ersetzen kann, wäre ein Wechsel dafür denkbar – so wie zuvor wegen des Geschwindigkeitsvorteils zu ruff gewechselt wurde. Für das Python-Paketmanagement werde eine dauerhafte Lösung gebraucht.

• Neugier auf die Entscheidung von uv, plattformspezifische requirements.txt-Dateien zu erzeugen

  • Es wird gefragt, warum uv plattformspezifische requirements.txt-Dateien erzeugt, statt plattformunabhängige poetry.lock- oder pdm.lock-Dateien zu erstellen.

• Glückwünsche und positive Reaktion auf die Arbeit des Astral-Teams

  • Zwar wurde Sorge über einen externen Versuch geäußert, das Python-Packaging zu „reparieren“, doch die Priorisierung von Kompatibilität wird ausdrücklich begrüßt. Positiv hervorgehoben wird auch, wie stark das Astral-Team auf Kompatibilität mit bestehenden Tools und Standards achtet.

• Frage zu Kompilierungsproblemen bei pip-Paketen

  • Wie soll der Kompilierungsbedarf mancher pip-Pakete, die von kompletten Toolchains wie gcc, g++, gtk oder Qt abhängen, weniger fehleranfällig und benutzerfreundlicher gemacht werden?