uv, der extrem schnelle Python-Paket- und Projektmanager, geschrieben in Rust

• uv ist ein auf Rust basierendes extrem schnelles Tool zur Verwaltung von Python-Paketen und -Projekten
• Es kann pip, pip-tools, pipx, poetry, pyenv, virtualenv usw. in einem einzigen Tool ersetzen
• Bietet bis zu 10–100-mal höhere Geschwindigkeit, spart Speicherplatz auf der Festplatte und stellt einen leistungsstarken Cache sowie Cross-Platform-Unterstützung bereit
• Enthält Funktionen für eine integrierte Entwicklungsumgebung wie Skripte, Projekte, Tools und die Verwaltung verschiedener Python-Versionen
• Ermöglicht moderne Python-Entwicklungs-Workflows, die für hohe Entwicklerproduktivität, große Projekte und schnelles Arbeiten optimiert sind

---

Einführung in das Open-Source-Projekt und seine Differenzierungsmerkmale

• uv integriert die Funktionen mehrerer bestehender Python-Verwaltungstools wie pip, pip-tools, pipx, poetry, pyenv, virtualenv und twine in ein einziges Tool
• Es wurde in Rust entwickelt und bietet dadurch sehr hohe Leistung; im Vergleich zu klassischem pip sind Installation und Synchronisierung 10–100-mal schneller
• Durch globalen Cache und Deduplizierung von Abhängigkeiten bietet es optimierte Festplattennutzung sowie eine intuitive CLI und vertraute pip-Kompatibilität
• Es kann als eigenständige ausführbare Datei auf verschiedenen Plattformen wie macOS, Linux und Windows installiert werden
• Zu den Stärken zählen eine eigenständige Installationsmethode, die Integration mit pip und pipx sowie automatische Updates durch das Tool selbst

Hauptmerkmale (Highlights)

• Mit dem einzelnen Tool uv lassen sich vielfältige Funktionen von pip, pip-tools, pipx, poetry, pyenv, twine und virtualenv ersetzen
• Bietet im Vergleich zu herkömmlichem pip eine 10–100-mal schnellere Installation/Aktualisierung/Synchronisierung
• Lockfile-basierte Verwaltung von Projektabhängigkeiten mit Unterstützung für Workspaces und ein universelles Lockfile
• Inline-Deklaration von Skriptabhängigkeiten und automatische isolierte Ausführung in getrennten Umgebungen
• Unterstützung für Verwaltung/Installation/Wechsel verschiedener Python-Versionen
• Unterstützung für die Ausführung und Installation von als Python-Paket verteilten Tools (als Ersatz für pipx)
• Kompatibilität mit der pip-Schnittstelle und zusätzliche Funktionen (Versionsüberschreibung, plattformunabhängige Auflösung usw.)
• Cargo-Style-Workspaces für große Projekte optimiert
• Globaler Cache zur Minimierung doppelter Abhängigkeiten und für effiziente Nutzung des Speicherplatzes
• Installation und Nutzung auch ohne Rust-/Python-Umgebung über curl oder pip, pipx möglich
• Multi-Plattform-Unterstützung für macOS, Linux, Windows usw.
• Entwickelt vom Team hinter Astral und Ruff

Projektverwaltung (Project Management)

• Vollständige Unterstützung für Abhängigkeiten, Umgebungen, Lock-Dateien und Workspaces auf Projektebene
• Automatische Projektinitialisierung und Erstellung einer virtualenv mit dem Befehl uv init
• Mit uv add lassen sich Abhängigkeiten hinzufügen; die Befehle uv lock und uv sync übernehmen automatisch Paketsynchronisierung und Sicherheitsprüfungen
• Ersetzt die Funktionen moderner Python-Projektverwaltungstools wie Poetry und Rye und gewährleistet dabei höhere Verarbeitungsgeschwindigkeit
• Unterstützt auch Build und Veröffentlichung (publish) von Projekten, die nicht von uv verwaltet werden

Skriptverwaltung (Scripts)

• In einer einzelnen Datei können Abhängigkeiten als Inline-Metadaten deklariert werden
• Bei der Ausführung eines Skripts werden automatisch eine isolierte virtuelle Umgebung und die Abhängigkeitsinstallation bereitgestellt
• Mit uv add --script lassen sich Abhängigkeiten pro Skript verwalten; der Befehl uv run führt sie isoliert aus
• Optimal für einmalige Skripte wie in Data Science oder Automatisierung

Tool-Verwaltung (Tools)

• CLI-Tools im Python-Paketformat können wie mit pipx installiert und ausgeführt werden
• Mit uv tool install und uvx sind temporäre Umgebungen oder globale Ausführung möglich
• Unterstützung für das Prüfen installierter Tools, Versionsverwaltung und Updates

Verwaltung von Python-Versionen

• Mehrere Python-Versionen lassen sich einfach installieren und sofort umschalten
• Verschiedene Versionen können parallel verwaltet werden; projektbezogenes Pinning über .python-version ist möglich
• Alternative Implementierungen wie pypy werden über dieselbe Schnittstelle unterstützt
• Mit Befehlen wie uv python install/pin lassen sich Versionen installieren, festlegen und aktivieren

pip-Schnittstelle (Pip Interface)

• uv pip und uv venv ersetzen bestehende Tools wie pip, pip-tools und virtualenv vollständig
• Enthält erweiterte Funktionen wie Überschreiben von Abhängigkeitsversionen, plattformunabhängige Auflösung und reproduzierbare Builds
• Dient als Drop-in-Ersatz für pip ohne Änderungen am bestehenden Workflow und bietet dabei eine 10–100-mal höhere Leistung
• Unterstützt die Umwandlung von requirements.in → requirements.txt, die Erstellung virtueller Umgebungen und die Synchronisierung von requirements

Plattformen und Versionsrichtlinien

• Unterstützung für verschiedene Betriebssysteme (Windows, macOS, Linux)
• Informationen zu Richtlinien und unterstützten Plattformen sind in der offiziellen Dokumentation verfügbar

Mitwirken (Contributing)

• Ziel ist die Unterstützung unterschiedlichster Beitragender von Einsteigern bis zu Expertinnen und Experten; entsprechende Leitfäden werden bereitgestellt

FAQ

• uv wird als „yu-vee“ ausgesprochen
• Die Schreibweise ist fest auf das kleingeschriebene „uv“ gesetzt

Technischer Hintergrund und Danksagungen (Acknowledgements)

• Für den Algorithmus zur Auflösung von Abhängigkeiten wird PubGrub verwendet
• Die Git-Implementierung basiert auf Cargo
• Die Optimierungsstrategien sind stark von modernen Packaging-Tools wie pnpm, Orogene, Bun und Posy inspiriert

Lizenz

• Kann wahlweise unter MIT oder Apache-2.0 verwendet werden
• Auch beigetragener Code ist unter denselben Bedingungen doppelt lizenziert

[GN⁺]

Hacker-News-Kommentare

• Bis vor ein paar Monaten dachte ich noch, dass ich uv niemals benutzen würde, weil ich bereits an venv und pip gewöhnt war und kein weiteres Tool brauchte. Aber nachdem ich kürzlich auf einem gemeinsam genutzten Server ohne Root-Rechte saß, auf dem diverse Pakete und Treiber kaputt waren und ich PyTorch brauchte, bin ich komplett zu uv gewechselt. pip brauchte ewig, der Cache fraß massenhaft Speicherplatz und ließ sich auch nicht gut verschieben. Mit uv funktionierte plötzlich alles hervorragend, und ich bin sehr zufrieden. Wenn du noch zögerst, probier es wenigstens mal fünf Minuten lang aus.

  • Der größte Vorteil von uv ist, dass es vollständig mit dem bisherigen venv-basierten Workflow kompatibel ist. Einfach uv venv ausführen, und das Problem ist gelöst.
  • uv fühlt sich viel einfacher an, wenn man es erklären oder besonders Einsteigern die Nutzung beibringen will. Die Kombination aus pip + Konfigurationsdateien + venv war verwirrend: Man musste daran denken, das richtige venv anzulegen und zu installieren, und bei jedem Skriptlauf/Test entweder eine unbeholfene Shebang-Zeile verwenden oder das venv aktivieren. Auch die Fehlermeldungen halfen nicht wirklich weiter. Beim Unterrichten von Einsteigern wirkten diese Tools immer unnötig umständlich. Jetzt müssen sie sich nur noch uv run, uv add und uv sync merken, und im Team wird das deutlich entspannter aufgenommen.
  • Ich bin selbst von asdf zu mise gewechselt und frage mich, wie sich das im Vergleich zu universellen Tools wie uv schlägt.
  • Du meintest, dass der pip-Cache viel Platz belegt und sich sein Speicherort nicht richtig ändern ließ. Mich würde interessieren, ob uv den Speicherplatz im Repository besser nutzt und, falls ja, ob das daran liegt, dass es besser teilt.
  • Ich habe kürzlich in einem experimentellen Repository eine einfache Anleitung gesehen, die mit „uv a b c“ beginnt, und sie ausprobiert. Intern scheint es viel Duplikation zu geben, aber im praktischen Einsatz auf einem GNU-Debian-Ubuntu-Standardhost gab es keinerlei Probleme und alles lief reibungslos, womit ich sehr zufrieden bin.

• Als ich uv zum ersten Mal benutzt habe, war es im Vergleich zu pip so schnell fertig, dass ich dachte, ich hätte etwas falsch gemacht oder es hätte gar nicht richtig funktioniert.

  • Manchmal dauert eine Paketinstallation nur etwa 200 ms, sodass zwischen dem Drücken der Eingabetaste und dem Erscheinen des Prompts nur eine minimale Verzögerung spürbar ist. Bei Poetry kann man in der Zeit dagegen fast einen Kaffee trinken gehen – der Geschwindigkeitsunterschied ist also sehr deutlich.
  • Ich hatte genau dasselbe Gefühl. Es läuft so geschmeidig, dass es sich gar nicht wie Python anfühlt.
  • Ich hatte kürzlich ein ähnliches Erlebnis und bin dadurch vollständig zu uv gewechselt.
  • Ich war auch skeptisch, aber nachdem ich es ausprobiert hatte, war ich so zufrieden, dass ich nicht mehr zurückkonnte.

• Ich denke, uv und ruff sind großartige Gegenbeispiele zu dem Spruch „Erfinde das Rad nicht neu“. Wenn das Ziel klar ist, kann dabei durchaus etwas entstehen, das dem Bestehenden weit überlegen ist.

  • Meistens ist dieser Spruch eher ein Ratschlag für Anfänger, die das Bestehende nicht gut genug kennen – also für Leute, die die Grenzen und Verbesserungsmöglichkeiten eines Systems nicht verstehen und vorschnell etwas neu erfinden wollen. Auf echte Experten trifft das nicht zu.
  • Sie haben das Rad nicht neu erfunden, sondern eher ein bestehendes Holzrad durch ein robusteres Material ersetzt, damit es sich mit zehnfacher Geschwindigkeit drehen kann.
  • Schon wenn man sich nur die Geschichte des Python-Paketmanagements anschaut, hat man den Eindruck, dass alle mit dem Anspruch antreten, es besser zu machen als zuvor.
  • Eigentlich ergibt schon das Sprichwort „Das Rad nicht neu erfinden“ keinen Sinn. Auch echte Räder haben wir ständig weiterentwickelt, und es gibt keinen Grund, warum wir in der Software nicht ebenfalls bessere Räder bauen sollten.
  • Leicht off-topic, aber ich frage mich, warum manche lieber die längere Formulierung „order of magnitude better“ verwenden statt einfach das kürzere „10x“.

• Auf kleinen bzw. leistungsschwachen Systemen (wie AWS T2.micro unter Windows) versucht uv zu viele gleichzeitige Downloads und läuft dann in Timeouts. Wenn man die Anzahl paralleler Downloads über die Umgebungsvariable UV_CONCURRENT_DOWNLOADS auf etwa 1–2 begrenzt, ist das Problem gelöst. Ich finde die Standardeinstellung von uv etwas zu aggressiv und fände es gut, wenn die automatische Thread-Anpassung pro Server künftig anhand der Download-Geschwindigkeit verbessert würde.

  • Das ist überhaupt kein ungewöhnlicher Sonderfall. Viele Nutzer betreiben Side Projects auf günstigen VPS-Instanzen – ich selbst auch oft, wenn auch nicht bei AWS. Danke fürs Teilen, und hoffentlich wird die automatische Erkennung noch verbessert.

• Ich probiere uv in letzter Zeit privat auf meinem Laptop aus, und als jemand, der an pip gewöhnt war, ist die gefühlte Geschwindigkeit so unglaublich hoch, dass ich mehrmals unsicher war, ob es wirklich korrekt ausgeführt wurde.

• Ich mag den Befehl uv add <mydependencies> --script mycoolscript.py, und wenn man oben #!/usr/bin/env -S uv run ergänzt, kann man Python-Skripte sofort ausführbar machen – für mich ein sehr nützliches Tool.

  • Ich habe Claude Project diese Methode mit einem spezialisierten Prompt beigebracht, sodass es auf Basis einer einzigen Eingabe automatisch ein komplettes Skript samt Abhängigkeiten erzeugen kann. Der Cutoff von Claude 4 liegt im März 2025, und in Claude Sonnet 4 funktioniert das sogar ohne zusätzlichen Prompt. Gibt man zum Beispiel eine URL ein, erzeugt es direkt Code, der mit httpx und beautifulsoup crawlt und eine Linkliste als CSV zurückgibt. Weiteres Material Claude-Skriptergebnis
  • Ich nutze diesen Trick zusammen mit dem App-Mode von Marimo.io-Notebooks. Wenn nur uv installiert ist, kann man anderen ohne großen Vorlauf sehr leicht reaktive, reproduzierbare Apps zum sofortigen Ausführen geben. Wirklich eine großartige Kombination.
  • Inzwischen habe ich mir angewöhnt, selbst kleine Skripte einfach spontan sofort auszuführen. Weil ich mich nicht mehr um Umgebung oder Abhängigkeitsmanagement kümmern muss, ist das deutlich angenehmer. Artikel zu the little scripter, passendes YouTube-Video, ez-mcp auf GitHub
  • Korrektur: Ich hatte das Beispiel falsch gelesen. Im Projektkontext sind uv add --script und ein einfaches uv add nicht dasselbe. Außerdem gibt es in der offiziellen Dokumentation noch viele nützlichere Funktionen wie run --with oder PEP723-Unterstützung – lohnt sich also, dort nachzusehen. Offizieller Leitfaden
  • Was genau ist eigentlich mit „mydependencies“ gemeint? Ist das im Sinne einer Konfigurationsdatei zu verstehen?

• Ich habe uv früher schon einmal ausprobiert und war überrascht, wie überwältigend schnell und zugleich einfach zu benutzen es ist. Inzwischen gibt es fast keinen Grund mehr, pip zu verwenden, und wenn man nur Python nutzt, braucht man auch conda nicht mehr.

  • pyenv und poetry verwende ich inzwischen ebenfalls nicht mehr.

• Ich mag UV wirklich sehr. Ich mag auch Ruff vom Astral-Team so sehr, dass ich mein bisheriges pylint + Black-Setup komplett auf Ruff für Linting und Formatting umgestellt habe. Bei mir ist die Lint-Zeit von 90 Sekunden auf unter 1,5 Sekunden gefallen – das war wirklich verblüffend.

  • Allerdings habe ich später enttäuscht festgestellt, dass ruff nur einen Teil der Prüfungen von pylint abdeckt und selbst übermäßig offensichtliche Fehler einfach durchgehen lässt (zum Beispiel nicht ausführbaren Code).

• Seit Kurzem gefällt mir dieses Muster für kleine ausführbare Skripte besonders gut, und ich benutze es gern:

  #!/usr/bin/env -S uv --quiet run --script
  # /// script
  # requires-python = ">=3.13"
  # dependencies = [
  #   "python-dateutil",
  # ]
  # ///
  #
  # [python script that needs dateutil]  
  

  • Die Shebang-Zeile ist viel zu schwer zu merken. Es wäre schön, wenn es einfach eine deutlich simplere Form wie #!/usr/bin/env uvx gäbe. So wie es jetzt ist, muss ich jedes Mal wieder danach suchen.

• Ich bin vollkommen überzeugt und möchte nicht mehr zu pip/twine/requirements.txt zurück. Mehrere Projekte hatten gemeinsame Wheels im internen GitLab liegen, und die bisherigen zehn Zeilen YAML lassen sich einfach durch uv build und uv publish ersetzen. Abhängigkeiten lassen sich bequem einbinden, und die wichtigsten Dependencies sieht man auf einen Blick. Das lästige Durcheinander, bei dem in requirements.txt alles zusammengeworfen wird, entfällt.