Ein Jahr uv: Vor- und Nachteile und was bei der Migration zu beachten ist

• uv hat sich nach einem Jahr Einsatz in verschiedenen Client-Umgebungen als deutliche Vereinfachung für den Start von Python-Projekten und das Dependency-Management erwiesen; wo möglich, lohnt es sich, es zuerst auszuprobieren
• Es behält den bisherigen pip/venv-Workflow weitgehend bei, arbeitet aber schneller und stabiler, sodass die Migrationskosten eher niedrig sind
• Python-Installation, virtuelle Umgebungen, Lockfiles, Ausführung, Build und das Ausführen temporärer Tools werden in einem Werkzeug gebündelt und senken so die Kosten für Projektexperimente erheblich
• Realistische Einschränkungen bleiben jedoch: scheiternde Auflösung von Legacy-Abhängigkeiten, der Unterstützungsumfang von python-build-standalone, ein Cache, der auf über 20 GB anwachsen kann, Unternehmens-Sicherheitsrichtlinien und die CLI-Hürde
• Wer weiter mit Python arbeitet, sollte auch bei Nutzung von uv pip und venv kennen und auf Umgebungen vorbereitet sein, in denen uv nicht erlaubt ist oder nicht passt

---

Wo Python-Projekte schwierig werden

• Die Wurzel des größten Problems in Python liegt im Bootstrapping: Python selbst bereitzustellen und ein neues Projekt zu starten
• Viele spätere Packaging-Probleme entstehen weniger durch die Installation von Abhängigkeiten oder das Bauen von Paketen selbst, sondern durch die anfängliche Python-Installation und Projekteinstellungen
• Die Installationswege für Python unterscheiden sich je nach Betriebssystem, ebenso die Defaults und Fallstricke
• Obwohl Python eine für Einsteiger geeignete Sprache ist, braucht man für die Installation überraschend viel Vorwissen
• Python wird von sehr unterschiedlichen Gruppen genutzt: Studierenden, Data Scientists, KI-Entwicklern, Webentwicklern, Systemadministratoren, Biologen, Geografen, Plugin-Entwicklern und vielen anderen
• Die Ausführungsumgebungen reichen von Windows-Rechnern in Unternehmen über private Debian-Laptops, Universitäten, Behörden, Startups, Militär, Forschungslabore bis zu Großunternehmen; mit einem einzigen Tutorial lässt sich das kaum alles abdecken
• PATH, PYTHONPATH, mehrere parallel installierte Python-Versionen, optionale Linux-Pakete, Python als Systemabhängigkeit und die Popularität kompilierter Extensions erhöhen die Komplexität
• Ein gutes Tool für das Management von Python-Projekten sollte folgende Bedingungen erfüllen
  • Es sollte unabhängig vom Python-Bootstrapping funktionieren
  • Es sollte Installation und Ausführung von Python über Plattformen und Situationen hinweg vereinheitlichen
  • Es sollte eine Brücke zu Basistools wie pip und venv schlagen
  • Es sollte einen starken Dependency Resolver haben
  • Es sollte einfache Installationen leicht abwickeln und auch komplexe Aufgaben ermöglichen, etwa unter einem anderen Betriebssystem gelockte Abhängigkeiten zu installieren
  • Es sollte einfach zu installieren und zu nutzen sein und vertrauenswürdig genug, um ihm einen wichtigen Teil des Stacks zu überlassen

Wie uv Bootstrapping angeht

• uv wird völlig unabhängig von Python installiert und aktualisiert; uv-Installation und Python-Installation beeinflussen sich gegenseitig nicht
• Pythons Bootstrapping-Probleme, PATH-Probleme und Import-Probleme wirken sich nicht auf uv selbst aus
• Die Verwirrung darüber, ob ein Tool systemweit oder in einer virtuellen Umgebung installiert werden soll oder wie sich neue Keywords und Deprecations auf uv auswirken, nimmt ab
• uv bot zunächst Schnittstellen für pip und venv, damit es mit bestehenden Projekten, Tools und Denkweisen zusammen genutzt werden kann
  • Das war eine Entscheidung mit Blick auf die bestehende Community und Legacy-Code
  • Nutzer müssen uv run, uv add und uvx nicht lernen, sondern können wie im bisherigen pip-/venv-Workflow arbeiten
  • Schon Geschwindigkeit und Zuverlässigkeit bei Standardaufgaben liefern einen Grund zur Migration
• uv bietet auch Python-Installation an
  • Installation auf allen Betriebssystemen auf einheitliche Weise
  • Keine Administratorrechte erforderlich
  • Funktioniert unabhängig vom System-Python
  • Mehrere Versionen können ohne Konflikte installiert werden
  • Stellt dieselbe Standardbibliothek bereit und enthält auch tkinter
  • Enthält auch Pypy-, No-GIL- und TCO-Versionen
  • Funktioniert ohne Shims, Kompilieren oder unvernünftige Defaults

Python-Installationserfahrung und python-build-standalone

• Das Beispiel uv python install pypy3.8 installiert Python 3.8.16 in 2,71 Sekunden
• Auf die gleiche Weise lässt es sich auch auf Mac oder Windows ausführen
• Fehlende Pakete rund um Tcl, OpenSSL oder Gzip, Konflikte mit anderen Python-Installationsquellen, betriebssystemspezifisch andere Paradigmen, fehlende Befehle und falsch gesetzte PATH-Variablen treten nicht auf
• Für die Python-Installation nutzt uv python-build-standalone; Astral hat dieses Projekt übernommen und verbessert es
• Astral versucht, diese Vorteile an das cPython-Upstream-Projekt zurückzugeben, und hat auch zu benachbarten Open-Source-Projekten beigetragen

Projektmanagement-Funktionen

• uv init erzeugt standardmäßig eine .venv, eine pyproject.toml, ein Git-Repository mit Python-.gitignore, eine README.md und eine hello.py
• Root-Abhängigkeiten können in pyproject.toml deklariert oder mit uv add hinzugefügt werden
• uv remove räumt das Repository korrekt auf
• uv lock --upgrade-package <package>==<version> ermöglicht es, Pakete vorsichtig versionweise zu aktualisieren
• uv build erstellt aus dem Projekt ein .whl-Paket, verlangt aber nicht zwingend, dass das Projekt buildbar ist
• uv run führt Befehle innerhalb der virtuellen Umgebung aus, auch wenn diese nicht aktiviert ist
  • Nutzer müssen weder wissen, dass eine virtuelle Umgebung existiert, noch das Aktivierungskonzept verstehen
• Diese Befehle aktualisieren Lockfiles automatisch und transparent
  • Weil uv schnell ist, merkt man die Aktualisierung kaum
  • Nutzer müssen nicht wissen, was ein Lockfile ist
• Lockfiles sind plattformübergreifend, sodass man unter Windows entwickeln und nach Linux deployen kann

Performance, Stabilität und Fehlermeldungen

• Die Performance von uv senkt die Kosten für Dependency-Installation und Projektexperimente
• Man kann schnell neu anfangen und mehrere Ansätze ohne große Hürde wiederholen
• Tools wie pyenv, pipenv oder poetry brachen in verschiedenen Umgebungen teils mit Stack Traces ab; uv erwies sich als sehr robust
• Bei Astrals Qualität fallen besonders drei Punkte auf
  • Bugs werden schnell behoben, auf Feedback und Reports wird reagiert
  • Eine starke Testkultur; die Testsuite für Dependency Resolution wird als eigenes Paket bereitgestellt
  • Die Fehlermeldungen sind sehr gut
• Das Beispiel uv add httpie==2 zeigt Schritt für Schritt, dass httpie==2.0.0 von requests>=2.22.0 abhängt, das Projekt aber requests==1 verlangt und die Anforderungen daher nicht erfüllbar sind
• Fehlermeldungen zur Dependency Resolution sind auch von pubgrub beeinflusst, doch die Fehlermeldungen in uv insgesamt folgen derselben Richtung
• Beim Einsatz von uv in der Lehre konnten Studierende ohne große Eingriffe produktiv arbeiten; mit anderen Tools gab es diese Erfahrung nicht
• Neue professionelle Projekte konnten leicht von uv profitieren, bei Legacy-Projekten können dagegen Blocker auftreten

uvx und neue Nutzungsweisen

• uv stellt starke und schnelle Grundbausteine für Vorbereitung und Isolation von Python und Abhängigkeiten bereit
• Früher waren die Vorbereitung von Python und Abhängigkeiten langsame und fragile Einschränkungen; mit uv lassen sie sich eher wie eine Funktion behandeln, mit der man Workflows anpasst
• uv run --with jupyter jupyter notebook startet Jupyter im aktuellen Projekt, fügt Jupyter und dessen Abhängigkeiten aber nicht zum Projekt hinzu
• uvx --with pendulum -p 3.13t python lädt und installiert einen neuen Python-No-GIL-Build, erstellt eine temporäre virtuelle Umgebung, installiert pendulum und startet anschließend die Python-Shell
• uvx ist ein Tool wie npx für Python und kann als richtig umgesetztes pipx betrachtet werden
• Unterstützung für Inline-Abhängigkeiten verändert, wie kleine Python-Skripte Abhängigkeiten nutzen
  • Früher musste man Abhängigkeiten in kleinen Skripten vermeiden oder umständliche Workarounds verwenden
  • Jetzt lassen sich Abhängigkeiten schnell, transparent und selbsterklärend nutzen
• Diese Funktionen werden nicht erzwungen; Nutzer können sie bei Bedarf entdecken und übernehmen

Wo uv scheitert oder unbequem ist

• uv kann reale Packaging-Probleme nicht anstelle anderer lösen
  • Probleme wie falsche Versionsmarker, fehlende Wheels oder Namenskollisionen liegen außerhalb der Kontrolle von uv
  • Solche Probleme stecken in der Datenqualität auf PyPI
  • Dass Packaging-Probleme mit uv seltener auftreten, liegt daran, dass es andere Teile korrekt handhabt
• Wegen des strengeren Dependency Resolvers können virtuelle Umgebungen von Legacy-Projekten brechen, die sich auf die lockere Auflösung alter pip-Versionen verlassen haben
  • In einem Fall mit einer 15 Jahre alten Codebasis, die gerade erst auf Python 3 migriert worden war und auf einer unbereinigten pip freeze-Historie stand, funktionierte uv nicht
• Die eingebaute Python-Installation von uv ist auf Versionen beschränkt, die mit python-build-standalone gebaut wurden
  • Über den Installer von python.org, deadsnake oder pyenv lassen sich mehr Python-Versionen installieren
  • Für ältere Projekte, die zwingend eine bestimmte Python-Version benötigen, kann das ein Problem sein
  • uv funktioniert gut mit extern installiertem Python, daher ist das kein vollständiger Blocker
• Ausführbare Dateien aus python-build-standalone können etwas langsamer sein
  • Laut pyperformance war Pythons 3.10 von uv 3 % langsamer als Pythons Ubuntu-Version
  • Man könnte Python bevorzugen, das mit Hardware-Optimierungen kompiliert wurde
• Auch der Cache-Speicherplatz kann ein Nachteil sein
  • Nach einem Jahr Nutzung belegte der uv-Cache auf der Festplatte über 20 GB
  • Mit uv cache clean lässt er sich löschen, doch dann verliert man den Geschwindigkeitsvorteil
  • Anders als pip hardlinkt uv Pakete, sodass sie nur einmal Platz belegen; daher kann der Verbrauch geringer sein als zuvor bei mehreren vollständigen virtuellen Umgebungen
• $UV_PYTHON war unbequem, weil es statt einer Standardversion eine Python-Version erzwang; das zugehörige Issue ist in Bearbeitung
• uv ist Open Source, aber ein Produkt des kommerziellen Unternehmens Astral
  • Astral ist noch nicht profitabel und hat auch noch kein kommerzielles Produkt veröffentlicht
  • Es gibt die Ansicht, man solle vorsichtig sein, bevor man einem wichtigen Teil des Stacks vertraut
  • Umgekehrt sind sowohl der Umstieg auf uv als auch der Ausstieg aus uv mit niedrigen Kosten verbunden
• Die größte Einschränkung ist die Einführung in Unternehmen
  • In stark abgesicherten und gesperrten Großunternehmensumgebungen ist die Installation neuer Abhängigkeiten sehr schwierig
  • Wenn IT-Sicherheitsabteilungen kontrollieren, was auf Maschinen getan werden darf, erlauben sie die Installation von uv möglicherweise nicht
  • Bis eine stabile Version erreicht ist und mehrere Anforderungen erfüllt sind, bleiben die Einschränkungen in Unternehmensumgebungen groß
• Auch die CLI ist eine Hürde
  • Nicht wenige Python-Nutzer sind mit der Kommandozeile nicht vertraut, besonders unter Windows
  • Das ist auch einer der Gründe, warum Anaconda eine GUI hat
  • Für komplette Anfänger ist die Anforderung eines CLI-Tools eine Einstiegshürde
• uvx und uv tool install ermutigen wie pipx dazu, Tools außerhalb des Projekts zu installieren
  • Für eigenständige Tools wie yt-dlp oder httpie ist das passend
  • Entwicklungstools wie mypy, die sensibel auf Python-Versionen oder Bibliothekssyntax reagieren, können Probleme verursachen, wenn sie in einer anderen Python-Version als das Projekt installiert sind

Wann man uv vermeiden sollte

• Es gibt fünf Situationen, in denen man uv nicht verwenden sollte
  • Man hat ein Legacy-Projekt, das mit uvs Dependency Resolution nicht funktioniert, und hat keine Kapazität oder keinen Wunsch, es für die Migration aufzuräumen
  • Die Unternehmensumgebung erlaubt die Nutzung von uv nicht
  • Man vertraut uv nicht, weil es noch keine stabile Version gibt, Astrals kommerzielles Produkt noch nicht erschienen ist oder der Pool an Rust-Beitragenden klein ist
  • Man braucht eine bestimmte Python-Version, die uv nicht anbietet, und möchte uv nicht mit extern installiertem Python nutzen
  • Für das Team ist die CLI eine zu große Hürde
• Vertrauensfragen und bestimmte Python-Versionen sind eher Entscheidungen als technische Blocker
• Bei Einschränkungen durch Unternehmensumgebungen kann der Nutzer meist nicht viel tun
• Praktisch entscheidend sind vor allem Legacy-Abhängigkeiten und die CLI-Hürde
• Der Rat ist einfach
  • Immer zuerst uv ausprobieren
  • Wenn es nicht funktioniert, zur alten Methode zurückkehren oder einen Workaround suchen
• Wenn die CLI das Problem ist, kann man für die Python-Bereitstellung den Installer von python.org verwenden und IDE-Plugins vorschlagen, die uv kapseln
• Wer programmieren kann, wird sich wahrscheinlich die für uv nötigen Kommandozeilen-Grundlagen aneignen können

Die künftige Rolle

• Für den Einsatz in Unternehmen gibt es bis v1 noch eine Lücke; da Unternehmen nicht häufig aktualisieren können, ist eine stabile Version wichtig
• Zu erwarten sind Bundling-Funktionen als Alternative zu pex/shiv und möglicherweise ein Build-Backend
• Eine Funktion zum Erzeugen von Installern für Anwendungen wirkt wie die logische Konsequenz, ist aber viel komplexer, weil schon korrektes Signieren schwierig ist
• Sobald Task-Unterstützung geklärt ist, wäre der Funktionsumfang für den persönlichen Bedarf ausreichend
• Wenn Python der Beruf ist, sollte man weiterhin lernen, wie pip und venv funktionieren
  • Denn irgendwann kann eine Situation auftreten, in der uv nicht verfügbar ist
• Unterm Strich ist uv eine Pareto-Lösung mit niedrigen Kosten und hohem Nutzen, die man in Umgebungen, in denen sie einsetzbar ist, zuerst ausprobieren sollte