uv ist die größte Innovation im Python-Ökosystem der letzten zehn Jahre

(emily.space)

29 Punkte von GN⁺ 2025-10-30 | 7 Kommentare | Auf WhatsApp teilen

uv vereinfacht die Installation von Python und die Verwaltung virtueller Umgebungen grundlegend und löst die Probleme komplexer Umgebungskonfigurationen im Python-Ökosystem
Es ist in Rust geschrieben und bietet sowohl Geschwindigkeit als auch Stabilität; Python-Versionsinstallation, Paketverwaltung und Abhängigkeitsauflösung werden mit einem einzigen Befehl erledigt
Es erkennt pyproject.toml automatisch und richtet die Projektumgebung ein; mit uv sync lässt sich eine vollständig identische Entwicklungsumgebung im Team reproduzieren
Mit Befehlen wie uv run, uv add und uvx sind Ausführung ohne Aktivierung einer virtuellen Umgebung sowie das Hinzufügen von Paketen und einmalige Ausführungen möglich
Durch konsistente Python-Installation und -Ausführung gilt uv als Wendepunkt, der die Produktivität von Entwicklern und die Effizienz der Zusammenarbeit deutlich steigert

Überblick über uv

uv ist ein von Astral entwickeltes kostenloses Open-Source-Tool zur Python-Verwaltung, das die komplexen Schritte der Umgebungskonfiguration vereinfachen soll
- Astral ist das Team hinter Python-Entwicklungswerkzeugen wie Ruff
- uv unterstützt die Installation von Python-Versionen, Paketinstallation, Verwaltung virtueller Umgebungen und Abhängigkeitsauflösung und ist in puncto Geschwindigkeit deutlich schneller als bestehende Tools
Es wurde in Rust entwickelt, bietet sehr hohe Leistung und läuft auf nahezu allen Plattformen wie macOS, Linux und Windows

Installation und grundlegende Nutzung

Die Installation ist sehr einfach und lässt sich mit einer einzigen curl- oder PowerShell-Zeile ausführen
- Linux/Mac: curl -LsSf https://astral.sh/uv/install.sh | sh
- Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Da bestehende Python-Installationen nicht verändert werden, kann man es gefahrlos ausprobieren

Verwaltung von Projektumgebungen

uv verwaltet für jedes Python-Projekt virtuelle Umgebungen automatisch und richtet die Umgebung anhand der Datei pyproject.toml ein
- In pyproject.toml werden Python-Version, Liste der Abhängigkeiten sowie Projektname und -version definiert
- Beispiel:
```
[project]  
name = "my_project"  
version = "1.0.0"  
requires-python = ">=3.9,<3.13"  
dependencies = ["astropy>=5.0.0", "pandas>=1.0.0,<2.0"]  
```
- Dieser Ansatz bietet im Vergleich zu pip eine klarere und stärker standardisierte Definition der Umgebung

Neues Projekt erstellen

Mit dem Befehl uv init lässt sich einfach ein neues Projekt erzeugen
- Dabei werden automatisch notwendige Dateien wie pyproject.toml und README.md erstellt
- Mit Optionen wie --bare und --package werden verschiedene Initialisierungsformen unterstützt
- Details zu den Optionen lassen sich mit uv init --help anzeigen

Bestehendes Projekt synchronisieren

Wenn ein Projekt bereits eine pyproject.toml enthält, kann es sofort mit dem Befehl uv sync verwendet werden
- Die passende Python-Version wird automatisch installiert
- Im Verzeichnis .venv wird eine virtuelle Umgebung erstellt
- Es wird eine uv.lock erzeugt, die die exakten Versionsinformationen aller Pakete festhält
Mit dem Befehl uv run lassen sich Python-Skripte auch ohne Aktivierung der Umgebung ausführen
- Beispiele: uv run myscript.py, uv run jupyter lab

Verwaltung von Abhängigkeiten und Python-Versionen

Mit dem Befehl uv add numpy>=2.0 lassen sich Abhängigkeiten automatisch hinzufügen und verwalten
- pyproject.toml muss dafür nicht direkt bearbeitet werden
Mit dem Befehl uv python pin 3.12.9 kann eine bestimmte Python-Version festgeschrieben werden, was die Reproduzierbarkeit der Umgebung sicherstellt

uvx: schnelle einmalige Ausführung

uvx ist ein Befehl, mit dem sich Tools ohne separate Umgebungseinrichtung sofort ausführen lassen
- Beispiele: uvx ruff, uvx jupyter lab, uvx --with pandas,pyarrow ipython
- Dank Cache-basiertem Ansatz sind erneute Ausführungen extrem schnell, was für experimentelle Arbeiten nützlich ist
Dadurch können Entwickler temporäre Laufzeitumgebungen unkompliziert einrichten, ohne an virtuelle Umgebungen gebunden zu sein

Falls dich das immer noch nicht überzeugt: eine persönliche Notiz

Bei der Entwicklung von The Astrosky Ecosystem wurde uv eingeführt, um Python-Umgebungen über mehrere Betriebssysteme hinweg zu vereinheitlichen
- Es hilft dabei, dass alle Entwickler und Server exakt dieselben Python-Installationen und Abhängigkeitsversionen verwenden
- Auch in GitHub Actions und auf Produktionsservern verwaltet uv die Python-Umgebung
Dank uv sind Probleme durch Unterschiede zwischen Installations- und Testumgebungen verschwunden, und die Zusammenarbeit zwischen Entwicklern wurde einfacher

Fazit

uv beseitigt die Komplexität der Python-Installation und -Verwaltung grundlegend und ermöglicht Entwicklern eine stabile Zusammenarbeit in identischen Umgebungen
Dank hoher Geschwindigkeit und der Stabilität durch Rust wird uv als „größte Innovation im Python-Ökosystem der letzten zehn Jahre“ bewertet

7 Kommentare

kkksss 2025-11-06

Ich dachte, pdm sei uv fast sehr ähnlich, aber man hört nicht viel über pdm.

yuntae 2025-10-30

Bei Beiträgen über uv scheint sich der Inhalt inzwischen kaum noch wesentlich zu ändern.

pmc7777 2025-10-30

Maven und Gradle auch..

GN⁺ 2025-10-30

Hacker-News-Kommentare

Früher hieß es immer, das Python-Tooling sei gut genug, aber jetzt, wo Python-Entwickler ein lockfile-basiertes Ökosystem wie bei npm, cargo oder bundler erlebt haben, ist es befriedigend zu sehen, dass sie die Vorteile erkennen.
npm hat auch Probleme, aber konsistente Installationen und Lockfiles sind wirklich ein großartiges Konzept.
- Es gibt kaum etwas Beängstigenderes, als das Python-Projekt einer anderen Person ausführen zu müssen.
  Erstaunlich, dass das Umgebungsmanagement so lange so unbequem war.
- Ich frage mich, warum das so lange gedauert hat.
  Ob die vielen gescheiterten Versuche einfach an der Schwierigkeit der Paketverwaltung lagen oder ob es VC-Finanzierung brauchte.
- Ich nutze schon lange pip freeze > requirements.txt und pip install -r requirements.txt.
  Wenn man keine Versionsbereiche verwendet, fungiert requirements.txt faktisch als Lockfile.
  Deshalb wirkt der aktuelle Hype um das „offizielle Lockfile“ auf mich etwas übertrieben.
- npm hatte auch eine Zeit lang kein Lockfile.
  Ich denke, dass npm sich vor allem durch das Auftauchen von yarn verbessert hat.
- Ich mache seit 1998 Webentwicklung und halte PNPM für deutlich besser als npm.
  Es ist schneller, effizienter und deterministisch.
  Mehr dazu unter pnpm.io/motivation
Mit UV-Skripten konnte ich MCP-Client/Server als einzelne Datei bereitstellen.
Zugehöriger Beitrag: MCP server in a file
Die meisten Skripte bestehen aus nur einer Datei; wenn man oben den folgenden Code ergänzt, wird das Leben viel einfacher.
#!/usr/bin/env -S uv run --script
Dann verhält sich das Skript wie eine eigenständig ausführbare Datei, und uv installiert die benötigten Module automatisch.
- Aus Sicherheitssicht birgt dieser Ansatz ein gewisses Risiko,
  weil der Autor des Skripts bösartige Abhängigkeiten verstecken könnte.
  Eine Whitelist-Funktion wäre wünschenswert.
- Mit dem Flag für das maximale Release-Datum nach heutigem Stand kann man Versionen auch ohne Lockfile fixieren.
  Einige Pakete lassen sich allerdings nicht nach Release-Datum erkennen (z. B. yaml).
- Zum Ausführen muss uv installiert sein, also ist es nicht vollständig standalone.
- /usr/bin/env -S muss unterstützt werden, und für die Abhängigkeitsnamen müssen die Distributionspaketnamen verwendet werden, wie sie auch bei uv pip install genutzt werden.
  Das ist der Standard PEP 723, den auch pipx unterstützt.
- Eine Internetverbindung ist erforderlich, und je nach Zustand des Repositorys könnten unterschiedliche Versionen installiert werden.
Vor uv hatte ich kein Interesse an Rust, aber dank uv verlagere ich nun performancekritischen Code nach Rust.
Ich wünschte, conda würde ganz verschwinden. In ML-Clustern werden conda-Umgebungen viel zu groß und die Reproduzierbarkeit leidet.
- Als conda-Alternative wurde mir das Rust-basierte pixi empfohlen. Es nutzt den PyPI-Solver von uv wieder.
- conda ist bei fixierten Abhängigkeiten zwar reproduzierbar, aber die Builds sind langsam.
- In einem ML-Cluster sollte ohnehin Containerisierung vorhanden sein, daher halte ich conda dort für unnötig.
- Ich frage mich, wie man mit uv CUDA-Abhängigkeiten verwaltet.
- Für einen Open-Source-Ansatz zum Management großer ML-Abhängigkeiten siehe Metaflow docs und den Fast Bakery-Blog
Früher war ich mit der Kombination aus pyenv + venv + pip + pipx völlig zufrieden, aber uv bietet
- eine sehr hohe Geschwindigkeit bei der Abhängigkeitsauflösung,
- eine deutlich bessere Benutzererfahrung mit uv run, uv add usw.,
- die Zusammenführung mehrerer Tools in einem
- und eine einfache Python-Installation.
Statt eine Umgebung zu aktivieren, ist es viel bequemer, vor den Befehl einfach uv zu setzen.
Auch das Python-Versionsmanagement wird einfacher, und pro Projekt hat es etwas von einem batteries-included-Gefühl.
Ob es langfristig stabil ist, weiß ich noch nicht, aber für neue Projekte nutze ich es inzwischen standardmäßig.
- Das Aktivieren einer Umgebung passt letztlich nur PATH und Prompt an.
  Manche mögen es nicht, dass uv die Umgebung automatisch erkennt.
  Ich sehe den Wert des Python-Versionsmanagements nicht ganz, aber mit uv geht das Neuerstellen von Umgebungen viel schneller.
- Mit vorangestelltem uv lassen sich Befehle stateless ausführen, was die Zusammenarbeit erleichtert.
- Ich nutze es zusammen mit mise für die automatische Aktivierung, aber das uv-Präfix bleibt trotzdem nützlich.
- Die Philosophie von uv ist, dass venv wegwerfbar ist. Wenn es Probleme gibt, löscht man einfach .venv.
- Eigentlich sollten solche Umgebungsfragen einfach „funktionieren“.
Dieser Blogpost deckt sich fast vollständig mit meinen Erfahrungen.
Weniger Reibung, mehr Einfachheit.
Ich hoffe, dass die Python-Community uv als Standardwerkzeug übernimmt.
Rust-basierte Tools haben die Geschwindigkeit der Rückkopplungsschleife komplett verändert.
Ich frage mich allerdings, wie Astral Geld verdient. Sie haben Investitionen erhalten, aber kein kostenpflichtiges Produkt.
- Das Geschäftsmodell von Astral besteht im Verkauf von Enterprise-Software, die in die Open-Source-Tools integriert ist.
  Zum Beispiel ein internes Paket-Registry-System.
  Zugehöriges Interview: Charlie Marsh Interview
- Ein Produkt mit Potenzial für einen kostenpflichtigen Service ist Pyx
- Auch Conda verdient Geld allein über den Zugang zu „sicherheitsgehärteten Paketen“.
  Wenn es 10 Millionen Python-Entwickler gibt, dürfte uv gut monetarisierbar sein.
Persönlich halte ich Typannotationen und die Abschaffung des GIL für wichtiger als uv.
uv ist noch in einer frühen Phase und hat auch Unannehmlichkeiten. Am Ende ist es eben noch ein weiterer Paketmanager.
- Ein Teil des Lobs für uv beruht eigentlich darauf, dass pip und venv dank standardisierter PEPs inzwischen besser geworden sind.
  Vor allem der neue Resolver von pip und die größere Verbreitung von Wheel-Distributionen haben viel bewirkt.
  Siehe dazu: Wheels are faster for pure Python
- Auf Sprachebene wäre die Abschaffung des GIL zwar die größere Veränderung, aber tatsächlich nützliche Anwendungsfälle gibt es bislang noch nicht viele.
- Type Hints sind bereits 2015 eingeführt worden und damit keine neue Funktion mehr.
- uv ist nicht einfach nur ein Paketmanager, sondern bietet großen Wert bei der Vereinfachung der Bereitstellung.
  Dass es in Rust geschrieben ist, ist ebenfalls interessant. Wie LLVM hat es eine Struktur, die auch andere Sprachen unterstützen könnte.
  Aus Sicht der Endnutzer ist uv deutlich besser, und wenn es für Maintainer unbequem ist, kann man dazu Feedback geben.
- Typannotationen sind gut für die Dokumentation, aber praktisch nur begrenzt nützlich.
  Mit einem Strict Mode wären vielleicht auch Performanceverbesserungen möglich, das würde aber der Sprachphilosophie widersprechen.
  Wenn conda tatsächlich verschwinden würde, wäre ich dennoch bereit, zu uv zu wechseln.
Ich mag uv nicht.
- Es versucht, zu viele Dinge zu tun: pip, pyenv, virtualenv und sogar ruff auf einmal zu ersetzen.
- Man muss uv pip verwenden, also ist es nicht einmal ein vollständiger Ersatz.
- Die Kompatibilität mit Docker ist ebenfalls schwach.
- Viele neue Umgebungsvariablen erhöhen die Komplexität.
- Ich finde es nicht ungewöhnlich, dass pyenv, virtualenv und pip getrennt existieren.
  Allerdings gehen auch pip und venv oft kaputt, und das Debugging wird dadurch noch schwieriger.
- Tatsächlich werden pip, pyenv und virtualenv ohnehin immer zusammen verwendet, daher ist ein integriertes Tool sinnvoll.
  uv ersetzt ruff nicht.
  An den Umgebungsvariablen muss man gar nichts ändern.
- uv pip ruft pip nicht auf, sondern bietet eine kompatible Schnittstelle.
  Tatsächlich ersetzt uv pip.
  Ich frage mich, welche Docker-Kompatibilitätsprobleme konkret gemeint sind.
- Mit uv add, uv sync und uv run ist die Verwaltung viel ergonomischer und schneller.
  Ausführliche Dokumentation: uv dependencies concepts
- Meiner Erfahrung nach erfüllt uv mehrere Rollen gut. Mich würde interessieren, welche konkreten Probleme dabei aufgetreten sind.

aer0700 2025-11-01

uv ist zwar angenehm schnell, aber ich frage mich auch, ob es nicht besser gewesen wäre, stattdessen pip zu verbessern.

ztaka 2025-11-02

Ich nutze es in ML und im Web sehr gern und hoffe, dass uv schnell zu einer langweiligen Standardtechnologie wird haha

doolayer 2025-10-30

Wenn man ein Repo sieht, das nur requirements hat und kein pyproject.toml, wirkt es inzwischen schon altmodisch, haha;