uv 0.12.7: Pakete, Projekte und Python-Versionen in einem Werkzeug
Ein extrem schneller, in Rust geschriebener Paket- und Projektmanager für Python.
Auf einen Blick
- Was ist das?
- Der in Rust geschriebene Manager ersetzt pip, pipx, poetry, pyenv und virtualenv hinter einer gemeinsamen Oberfläche. Einordnung von Arbeitsweise, Befehlen und Versionsstand.
- Für wen ist es gedacht?
- Geeignet ist uv für Teams, die Abhängigkeiten, virtuelle Umgebungen und Interpreterversionen aus einer Hand verwalten wollen und die genannten Befehle in ihre Abläufe einbauen können. Weniger geeignet ist es für Projekte, die auf ein stabiles 1.0-Verhalten angewiesen sind, denn die Releases stehen bei 0.12.x, und bei 2.854 offenen Issues sind Änderungen am Verhalten zwischen Versionen wahrscheinlich.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
uv 0.12.7: Pakete, Projekte und Python-Versionen in einem Werkzeug
Die Beschreibung des Repositories lautet: ein extrem schneller Python-Paket- und Projektmanager, geschrieben in Rust. astral-sh/uv steht unter Apache-2.0, verweist als Dokumentation auf https://docs.astral.sh/uv und kommt auf 89.193 Sterne, 3.524 Forks sowie 2.854 offene Issues. Die letzte Änderung datiert vom 27. August 2026.
Die Releases-Liste nennt 0.12.7 vom 27. August 2026, 0.12.6 vom 25. August 2026 und 0.12.5 vom 14. August 2026. Der Abstand zwischen den beiden letzten Veröffentlichungen beträgt also zwei Tage. Wer uv in einer Pipeline einsetzt, sollte die Version festschreiben und nicht mit einer Bereichsangabe arbeiten.
Der Anspruch ist breit. Laut README soll uv pip, pip-tools, pipx, poetry, pyenv, twine und virtualenv ersetzen und darüber hinaus Arbeitsbereiche im Cargo-Stil, Skripte mit Inline-Metadaten und eine pip-kompatible Schnittstelle bieten. Getragen wird das Projekt von Astral, das auch Ruff und ty entwickelt.
install.sh, pip install uv und uv self update: die Installationswege
Der empfohlene Weg führt über ein eigenes Installationsskript. Unter macOS und Linux lautet der Aufruf `curl -LsSf https://astral.sh/uv/install.sh | sh`, unter Windows `powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"`. Das README betont, dass dafür weder Rust noch Python vorhanden sein muss.
Daneben gibt es die Wege über die Paketquellen selbst: `pip install uv` und `pipx install uv`. Für Umgebungen, in denen ein Skript aus dem Netz nicht erlaubt ist, ist das die einzige Option. Weitere Methoden listet die Installationsdokumentation auf.
Wer das Installationsskript genutzt hat, kann anschließend mit `uv self update` auf die neueste Fassung wechseln. Dieser Befehl aktualisiert das Werkzeug selbst und nicht die Pakete eines Projekts, was bei einer derart kurzen Releasefolge hilfreich ist, auf einem Server aber bewusst ausgelöst werden sollte.
uv init, uv add und uv lock: der Projektablauf im Konsolenbeispiel
Das README zeigt einen vollständigen Durchgang. `uv init example` legt ein Projekt an, `uv add ruff` erzeugt eine virtuelle Umgebung unter .venv, löst zwei Pakete in 170 Millisekunden und installiert ruff in der damals aktuellen Fassung 0.5.0. Anschließend läuft `uv run ruff check` und meldet, dass alle Prüfungen bestanden sind.
Danach folgen `uv lock`, das im Beispiel zwei Pakete in 0,33 Millisekunden auflöst, und `uv sync`, das die Umgebung mit dem Inhalt der Lockdatei abgleicht. Diese Trennung ist der Kern des Projektmodells: Die Lockdatei hält das Ergebnis der Auflösung fest, sync stellt die Umgebung danach her.
Für die Zusammenarbeit im Team ist die Lockdatei der wichtigste Teil. Das README spricht von einer universellen Lockdatei und verweist auf eine eigene Seite zur Projektstruktur. Ergänzt wird das durch Arbeitsbereiche im Cargo-Stil für mehrere Teilprojekte sowie durch einen globalen Zwischenspeicher, der Abhängigkeiten über Projekte hinweg nur einmal ablegt.
uv add --script und uv run: Abhängigkeiten in einer einzelnen Datei
Für Ein-Datei-Skripte bietet uv einen eigenen Weg. Eine Datei example.py mit einem einzelnen Aufruf von requests bekommt ihre Abhängigkeit über `uv add --script example.py requests` und trägt sie danach als Inline-Metadaten in sich. Beim Aufruf mit `uv run example.py` liest uv diese Metadaten, erzeugt eine isolierte Umgebung und installiert im Beispiel fünf Pakete in 12 Millisekunden.
Damit lässt sich ein Werkzeugskript weitergeben, ohne dass eine Umgebung, eine Anleitung oder eine zweite Datei mitreist. Wer Skripte in Cron-Jobs oder in der Administration einsetzt, spart sich die Frage, in welcher Umgebung sie laufen sollen.
Eine Einschränkung ergibt sich daraus für die Wiederverwendung: Die Abhängigkeiten stehen in der Datei selbst, sind also nicht mit einer zentralen Lockdatei des Projekts abgeglichen. Für produktive Anwendungen ist der Weg über ein Projekt mit Lockdatei die passendere Form.
uv python install 3.12 3.13 3.14 und die Datei .python-version
Auch die Interpreterversionen verwaltet uv selbst. Der Aufruf `uv python install 3.12 3.13 3.14` legt laut Beispiel drei Versionen in 972 Millisekunden an, konkret cpython-3.12.12, cpython-3.13.9 und cpython-3.14.0 für macOS auf ARM. Mit `uv venv --python 3.12.0` wird eine Umgebung gegen eine bestimmte Version erzeugt.
Für einmalige Läufe lässt sich die Version direkt angeben, im Beispiel `uv run --python pypy@3.8 -- python --version`, was eine PyPy-Installation samt Versionsangabe zeigt. Wer eine Version dauerhaft an ein Verzeichnis binden will, nutzt `uv python pin 3.11`, was eine Datei .python-version anlegt.
Damit verschwindet ein Werkzeug aus der Kette, das sonst separat installiert wird. Für Teams mit mehreren Projekten auf unterschiedlichen Interpreterständen ist die Datei .python-version der tragende Mechanismus, weil sie mitwandert und von uv gelesen wird.
uv pip compile --universal: der Umstieg ohne neue Arbeitsweise
Wer nicht auf das Projektmodell wechseln will, kann die vorhandenen Abläufe beibehalten. `uv pip compile requirements.in --universal --output-file requirements.txt` erzeugt eine plattformunabhängige Datei und löst im Beispiel 43 Pakete in 12 Millisekunden. Mit `uv venv` entsteht die Umgebung, `uv pip sync requirements.txt` stellt den Inhalt her.
Die Schnittstelle deckt nach eigener Aussage die gebräuchlichen Befehle von pip, pip-tools und virtualenv ab und erweitert sie um Überschreibungen von Versionen, plattformunabhängige Auflösungen und verschiedene Auflösungsstrategien. Das ist der Weg mit dem geringsten Risiko, weil requirements.txt weiter das Austauschformat bleibt.
Zwei Punkte bleiben offen. Die Angabe, uv sei 10- bis 100-mal schneller als pip, verweist auf eine Datei BENCHMARKS.md im Repository, deren Inhalt im Material nicht enthalten ist; die Zahlen sind damit selbst berichtet. Und wer eine ausgebaute poetry-Konfiguration hat, tauscht beim Umstieg deren Modell gegen die Lockdatei von uv, was mehr bedeutet als ein anderer Befehl. Die Alternative, pip und virtualenv weiter zu verwenden und uv nur über `uv pip` als schnelleren Installateur einzusetzen, behält beide Welten: gewohnte Abläufe, aber keine Arbeitsbereiche, keine Skript-Metadaten und keine Interpreterverwaltung aus einer Hand.
Redaktionelles Fazit
Geeignet ist uv für Teams, die Abhängigkeiten, virtuelle Umgebungen und Interpreterversionen aus einer Hand verwalten wollen und die genannten Befehle in ihre Abläufe einbauen können. Weniger geeignet ist es für Projekte, die auf ein stabiles 1.0-Verhalten angewiesen sind, denn die Releases stehen bei 0.12.x, und bei 2.854 offenen Issues sind Änderungen am Verhalten zwischen Versionen wahrscheinlich. Vor dem Umstieg empfiehlt sich der Weg über `uv pip compile requirements.in --universal`, weil damit die bestehende Datei weiterverwendet werden kann und sich der Geschwindigkeitsgewinn ohne neue Lockdatei beurteilen lässt.
Community-Notizen