Code-Formatierungsfunktion wird experimentell in uv eingeführt

• In der neuen uv-Version wird experimentell eine Code-Formatierungsfunktion bereitgestellt
• Der Befehl uv format verwendet intern den Formatter von Ruff, um Python-Code konsistent zu formatieren
• Damit ist einfaches Aufräumen von Code nur mit uv möglich, ohne ein separates Tool
• Nutzer können über zusätzliche Argumente das Formatierungsverhalten im Detail anpassen
• Da es sich noch um eine experimentelle Funktion handelt, sind Änderungen bei Befehlsweise, Fehlerbehandlung usw. möglich

---

Überblick

Das neueste Release von uv (0.8.13) führt die experimentelle Befehlsfunktion uv format ein, auf die Python-Entwickler lange gewartet haben. Mit dieser Funktion lässt sich die Code-Stil-Formatierung allein mit uv im Projekt durchführen, ohne zusätzliche Formatierungswerkzeuge separat verwalten zu müssen.

Was ist uv format?

• Der Befehl uv format bietet Python-Code-Formatierung über die uv-Oberfläche
• Intern wird der Ruff-Formatter aufgerufen, um den Code automatisch und konsistent zu formatieren

Hinweise für Entwickler

Charlie Marsh (uv-Entwickler) erklärte dazu auf Hacker News:

Ruff und uv werden nicht zusammengeführt und bleiben weiterhin getrennte Tools
Ziel ist einfach, die Nutzungserfahrung zu verbessern, sodass Anwender den Formatter verwenden können, ohne ihn als separates Tool wahrzunehmen
Ähnlich wie die Beziehung zwischen cargo fmt und rustfmt im Rust-Ökosystem

Verwendung

• Es muss uv in Version 0.8.13 oder höher verwendet werden
• Wenn der Befehl uv format im Projekt-Root ausgeführt wird, entspricht die Wirkung der Ausführung von ruff format
• Die Ausführung folgt der Befehlsoberfläche von uv

Übergabe zusätzlicher Argumente

• In der Form uv format -- [zusätzliche Argumente] lassen sich Detailoptionen zur Übergabe an Ruff festlegen
• So können die Benutzerfreundlichkeit von uv und die feingranularen Einstellungen von Ruff gleichzeitig genutzt werden

Hinweis zur experimentellen Phase

• Die Funktion befindet sich derzeit in einer experimentellen Phase, daher können sich Befehlsweise oder die Integration in die Projektstruktur künftig ändern
• Auch Fehlerbehandlung und Ausgabeformat sollen fortlaufend verbessert werden
• Die Funktion soll unter Einbeziehung von Nutzerfeedback weiterentwickelt werden

Abschluss

• Wer in Python-Projekten einfache und konsistente Code-Formatierung benötigt, kann uv format aktiv ausprobieren
• Da es sich um eine experimentelle Einführung handelt, kann direktes Ausprobieren mit anschließendem Feedback zur Weiterentwicklung von uv beitragen

[GN⁺]

Hacker-News-Kommentare

• Es wäre wohl besser, wenn ruff mit ty zusammengeführt würde; uv sollte sich auf Paket- oder Projektmanagement konzentrieren und sich nicht auch noch um die Bearbeitung des Code-Stils kümmern. Meiner Ansicht nach sollte uv Code-Dateien nur im Fall von Abhängigkeits-Updates (PEP 723) ändern.
  • Ich möchte klarstellen, dass ruff und uv nicht zusammengeführt werden und weiterhin getrennte Tools bleiben. Ziel ist vielmehr, Nutzern, die sich nicht separat um einen Formatter kümmern möchten, ein einfacheres Erlebnis zu bieten. Das ist ähnlich wie bei Rusts Cargo, wo cargo fmt intern rustfmt ausführt.
  • Es ist also eine Nachahmung der Art, wie cargo fmt in Rusts cargo vorhanden ist.
  • Im Kern ist das Ziel, uv zu einem vollständigen Python-Paketmanager zu machen, wobei die einzelnen Werkzeuge bei Bedarf auch separat nutzbar bleiben. uv ist also so etwas wie Cargo für Python, und wer nur einen schnellen Typechecker braucht, sollte nur ty verwenden können, während jemand, der nur Formatter/Linter braucht, nur ruff wählen kann. In diesem Sinne ergibt eine Zusammenlegung von ruff und ty nicht besonders viel Sinn.
  • Ich frage mich allerdings, wie es wäre, wenn irgendwann auch ty in uv integriert würde. Da alles von astral.sh kommt, könnte das Teil der Vision sein, aber ty scheint dafür noch nicht bereit zu sein.
  • Als nächsten Schritt fände ich es eine logische Weiterentwicklung, eine Option wie uv lint einzuführen, die intern ty ausführt. Idealerweise könnte man ein Python-Projekt mit einem einzigen Standardbefehl oder einer Reihe von Kommandos vorbereiten – formatieren, linten, testen, veröffentlichen. Vielleicht ist genau das die Vision hier.
• Ich nutze uv wirklich gern, bin aber etwas besorgt, dass es unnötig immer umfangreicher wird. Zum Beispiel unterstützen viele Subkommandos sehr viele eigene Flags, von denen manche fast dasselbe Ergebnis liefern (uv run --no-project und uv run --active usw.). Statt ständig neue Funktionen hinzuzufügen, würde ich mir wünschen, dass man sich stärker auf die Verbesserung bestehender Tools und der Dokumentation konzentriert.
  • Python-Projekte stabil, reproduzierbar und portabel zu machen, ist wirklich schwierig. uv sync ist theoretisch sehr nützlich, weil dabei nur erneut reproduzierbare Paketsätze gebaut werden, aber komplexe Pakete wie torch-tensorrt oder flash-attn können je nach Umgebung zwangsläufig variieren. Die Python-Community neigt oft dazu, Probleme nach dem Muster „bei mir funktioniert es“ zu individualisieren, aber die Kosten dafür, Software verteilbar, sicher, wiederholbar und zuverlässig zu machen, verschwinden nie. Am Ende zahlt jemand diesen Preis später unter stärker eingeschränkten Bedingungen. Es ist wirklich schwer, all diese unterschiedlichen Nutzer- und Betriebsanforderungen gleichzeitig zu erfüllen.
  • Ich verstehe nicht ganz, warum das Hinzufügen von Subkommandos zu uv als Aufblähung gesehen wird. uv ist ohnehin schon ein komplexes Tool und zudem gut dokumentiert. Solche intuitiven und selbsterklärenden Kommandos lassen sich meiner Meinung nach ganz natürlich ergänzen.
  • Wenn über uv so gesprochen wird, fühlt es sich ein bisschen an, als würde man sagen: „Der make-Befehl hat zu viele Targets.“
  • Ich frage mich, ob diese Optionen in die Haupt-Binärdatei eingebaut werden oder ob sie wie bei apt oder cargo als separate Binärdateien funktionieren.
• Ich halte dieses Update eindeutig für eine gute Entscheidung. Ich verstehe nicht, warum so viele Leute gegen eine bessere Richtung sind. Natürlich stimmt es, dass man das „schon auf eine etwas umständlichere Weise machen kann“, aber genau das ist es eben: „etwas umständlicher“.
  • Ich finde nicht, dass es schlimm ist, wenn uvx ruff format ein Wort länger ist. Verwirrender könnte eher sein, dass unklar wird, welcher Formatter tatsächlich ausgeführt wird, ob ruff automatisch installiert wird oder ob wie bisher Tools heruntergeladen und gecacht werden.
  • Dem stimme ich stark zu. Noch besser wäre es sogar, wenn man den Formatter in pyproject konfigurieren könnte.
  • Mein größter Kritikpunkt ist derzeit, dass es offenbar keine Unterstützung für andere Formatter gibt. Wenn mein Projekt black verwendet, funktioniert uv format nicht.
• Ich persönlich freue mich sehr auf diese Änderung, weil sie das Code-Formatting in meinem kleinen Team – dessen Hauptmitglieder Aktuare sind – radikal vereinfachen dürfte. uv hatte ohnehin schon großen Einfluss auf die Einführung und das Onboarding von Python bei uns, deshalb ist jede Möglichkeit willkommen, die Codequalität leichter zu verbessern. Natürlich könnte man auch einfach nur ruff separat verwenden oder eine pre-commit-Konfiguration einrichten, aber das einfache mentale Modell uv <Funktion> hilft dem Team enorm. Es wäre schön, wenn auch eine Integration mit anderen Formattern möglich wäre, und wenn sogar SQL-/dbt-Modell-Formatting unterstützt würde, hätte ich kaum noch Wünsche offen. Ich werde es erst einmal ausprobieren und sehen, welches Potenzial darin steckt.
  • Wenn man so viel Multi-Formatting braucht, ist es vielleicht besser, ein Makefile oder eine justfile zu verwenden. Dann kann man mit just format Python/SQL/Bash/TypeScript in einem Rutsch formatieren.
• Das wirkt für mich ein wenig wie Feature Overload. Ich benutze uv seit über einem Jahr immer mehr und kenne seine Vorteile, aber es ist noch immer nicht meine erste Wahl, und solche Änderungen werden das wohl auch nicht verbessern.
  • Mich würde konkret interessieren, was an diesem Ansatz problematisch sein soll. Go, Rust und Elixir verfolgen alle so eine Methode, und in den jeweiligen Sprachökosystemen macht das die Einrichtung und Nutzung von Projekten deutlich einfacher. Die Community kann sich auf ein gemeinsames Toolset konzentrieren, und sowohl Einsteiger als auch Experten bekommen einen konsistenten Einstiegspunkt.
  • Falls das so ist, würde mich interessieren, welches Tool du dann am meisten bevorzugst.
• Irgendwann werden die Funktionen von ruff wahrscheinlich in uv und ty aufgehen. Linting könnte intelligenter werden, wenn es von ty übernommen wird, das die Codebasis besser versteht, und Formatting passt gut zu uv, dessen Hauptzweck das Projektmanagement ist.
  • Da ty bereits im selben Repository wie ruff liegt, scheint eine Integration auch gar nicht so fern zu sein.
• Paketmanager sind für die Paketinstallation in Betriebsumgebungen unverzichtbar, aber ihre Vermischung mit reinen Entwicklungswerkzeugen wirkt auf mich wie eine Art „verführerische, aber gefährliche Falle“. Sicher, Go und Rust machen das auch, aber wenn man grundsätzlich darüber nachdenkt, scheint das keine besonders gute Struktur zu sein.
  • Das klingt vielleicht ziemlich negativ, aber aus der Perspektive von jemandem, der viel mit cargo gearbeitet hat, hätte ich gern mehr solcher „schlechten Ideen“. Wenn uv in Python eine ähnliche Rolle wie cargo einnimmt, wird die Python-Entwicklererfahrung enorm besser. Nach über 25 Jahren mit Python, in denen ich mich durch viele Schwächen hindurcharbeiten musste, finde ich es äußerst befriedigend, dass nun fast alles ohne großes Nachdenken einfach mit uv möglich wird.
• Das neue uv format ist im Grunde nur eine Abkürzung für uv run --with ruff ruff.
• Mir gefällt diese Richtung wirklich sehr. Wenn es nach mir ginge, würde ich es uv fmt nennen und etwas wie uv vet ebenfalls in die Roadmap aufnehmen.
• Es gibt bereits viele bewährte Code-Formatter, deshalb sehe ich überhaupt keinen Grund, das einzuführen. Es wirkt nur wie eine weitere Funktion, und ich habe nicht vor, es vorerst in irgendeine Pipeline aufzunehmen.
  • uv format ist im Grunde eher ein Frontend für ruff format; es kommt also kein neuer Formatter hinzu.
  • Es wäre gut, wenn man wüsste, dass das nur eine Abkürzung dafür ist, das ohnehin schon von vielen Leuten genutzte ruff format bequem aufzurufen.