Simon Willison stieß auf CI-Fehler mit Ruff v0.16.0. Die Standardwerte hatten sich geändert

Simon Willison stellte fest, dass mehrere CI-Jobs fehlschlugen, nachdem Ruff v0.16.0 seine standardmäßigen Lint-Regeln von 59 auf 413 erweitert hatte. Seine nicht fixierte Ruff-Entwicklungsabhängigkeit hatte das neue Release unbemerkt in bestehende Python-Projekte übernommen.

Astral veröffentlichte die Version am 23. Juli 2026. Zwei Tage später beschrieb Willison, wie das Update ohne bewusstes Upgrade in seine Builds gelangte. Die Fehler machten aus einem Linter-Release eine praktische Warnung vor Problemen beim Abhängigkeitsmanagement.

Der zentrale Konflikt besteht nicht zwischen strengerem Linting und schwächerem Code. Es geht um Ruffs verbesserte Sicherheit ohne Konfiguration im Verhältnis zu der Stabilität, die Entwickler von unveränderten Repositories erwarten. Diese Spannung ist überall relevant, wo CI bei jedem Lauf die neuesten verfügbaren Entwicklungstools installiert.

Ruff v0.16.0 veränderte die Bedeutung von „Standard“

Die folgenreichste Änderung in Ruff v0.16.0 ist kein neuer Befehl. Sie ist eine deutlich umfassendere Definition dessen, was nicht konfigurierte Projekte als Fehler betrachten sollten.

Ruff ist ein in Rust geschriebener Python-Linter und -Formatter. Ein Linter analysiert Quellcode auf Fehler, verdächtige Muster und ausgewählte Stilprobleme, ohne das Programm auszuführen.

Vor diesem Release aktivierte Ruff 59 Regeln, wenn ein Projekt keine explizite Lint-Auswahl vorgab. Version 0.16.0 aktiviert unter derselben Bedingung 413 Regeln, wie Astrals Migrationsleitfaden erläutert.

Das entspricht einem Zuwachs von 354 aktiven Prüfungen. Außerdem bewertet eine Standardinstallation von Ruff nun fast siebenmal so viele Regeln wie zuvor.

Auch der zugrunde liegende Regelkatalog ist gewachsen. Als Ruff seine Standardwerte zuletzt in Version 0.1.0 änderte, unterstützte es 708 Regeln. Astral zufolge umfasst die aktuelle Sammlung 968 Regeln.

Die alten Standardwerte wählten vor allem Teile von Pyflakes und pycodestyle aus. Projekte konnten Ruff übernehmen, ohne sofort detaillierte Entscheidungen über die zahlreichen integrierten Regelfamilien treffen zu müssen.

Diese konservative Basis half Ruff, sich in bestehende Repositories einzufügen. Sie führte jedoch auch zu einer wachsenden Lücke zwischen dem, was das Tool wusste, und dem, was es automatisch meldete.

Astral schloss einen großen Teil dieser Lücke mit Version 0.16.0. Die neuen Standardwerte greifen auf zusätzliche Familien zurück, darunter flake8-bugbear, pyupgrade und Ruffs eigene Kategorie RUF.

Flake8-bugbear konzentriert sich auf wahrscheinliche Fehler und fragwürdige Entwurfsmuster. Pyupgrade erkennt Syntax- und Standardbibliotheksmuster, die für die unterstützte Python-Version eines Projekts modernisiert werden können.

Die Liste der Standardregeln enthält nun Prüfungen, die Syntaxprobleme und unmittelbare Laufzeitfehler aufdecken können. Dabei geht es nicht bloß um Vorlieben bei Abständen oder Benennungen.

Dieser Unterschied erklärt, warum Ruff-CI-Fehler Aufmerksamkeit verdienen können. Einige neue Meldungen decken Defekte auf, die zuvor nur bestanden, weil Ruff den entsprechenden Detektor nicht automatisch aktiviert hatte.

Andere Meldungen betreffen Wartbarkeit, Modernisierung oder Muster, die ein Team bewusst akzeptiert. Eine größere Standardregelmenge kann nicht die Kompatibilitätsanforderungen oder Designkonventionen jedes Repositories kennen.

Ruff v0.16.0 verändert daher zwei Dinge gleichzeitig. Es erhöht die automatische Fehlererkennung und verlagert mehr Richtlinienentscheidungen in das erste Upgrade nach dem 23. Juli.

Das Release formatiert außerdem standardmäßig Python-Codeblöcke in Markdown-Dateien. Unterstützte umschlossene Blöcke umfassen python, py, python3, py3, pyi und pycon.

Dieses Verhalten ist für Repositories mit Dokumentation, Tutorials oder Quarto-Notebooks relevant. Eine Formatierungsprüfung kann nun Änderungen außerhalb herkömmlicher .py-Dateien erkennen.

Ruffs Release Notes beschreiben zudem neue Unterdrückungskommentare und umfangreichere Diagnoseausgaben. Diese Verbesserungen helfen Entwicklern, mit den zusätzlichen Befunden umzugehen, sobald sie auftreten.

Die Änderung des Umfangs bleibt das wichtigste Migrationsereignis. Ein Befehl, der sich letzte Woche vorhersehbar verhielt, kann heute bei identischem Quellcode einen von null abweichenden Exit-Code zurückgeben.

Warum Simon Willisons CI-Fehler wichtig sind

Simon Willisons Erfahrung zeigt, wie ein Update eines Entwicklungstools die wirksame Richtlinie eines Repositories verändern kann, ohne das Repository selbst zu verändern.

Willison ist ein unabhängiger Entwickler und Autor, der für Projekte rund um Python, Datentools und generative KI bekannt ist. Zu Beginn seiner Karriere entwickelte er außerdem das Django-Webframework mit.

Am 25. Juli schrieb Willison, dass seine „verschiedenen CI-Jobs“ zu scheitern begonnen hätten. Er führte die Fehler auf die neuen Ruff-Standardwerte und eine nicht fixierte "ruff"-Entwicklungsabhängigkeit zurück.

Sein Bericht über Ruff liefert eine konkrete Nutzerperspektive auf das Release. Der Repository-Code hatte sich nicht zwingend verschlechtert, doch seine Validierungsumgebung hatte sich darunter verändert.

Ein CI-Job oder Continuous-Integration-Job führt automatisierte Prüfungen aus, wenn Entwickler Änderungen vorschlagen oder zusammenführen. Teams sind auf konsistente Ergebnisse angewiesen, um zu entscheiden, ob Code sicher übernommen werden kann.

Installiert ein Job ruff ohne Versionsbeschränkung, kann der Paketresolver das neueste verfügbare Release auswählen. Der nächste Build kann dann Verhalten durchsetzen, das kein Maintainer ausdrücklich geprüft hat.

Dieser Fehlermodus lässt sich leicht abtun, weil Ruff normalerweise eine Entwicklungsabhängigkeit ist. Üblicherweise wird es nicht zusammen mit der Anwendung ausgeliefert, die Nutzer bedient.

Doch Entwicklungsabhängigkeiten bestimmen, ob Software ihre Auslieferungspipeline durchlaufen kann. Ein neuer Linter-Exit-Code kann einen Pull Request blockieren, ein Release anhalten oder Stunden an Untersuchung kosten.

Der Vorfall legt zudem eine irreführende Unterscheidung zwischen Laufzeitabhängigkeiten und Tools offen. Laufzeitpakete beeinflussen, was bereitgestellte Software tut, während Tools beeinflussen, ob Entwickler sie überhaupt bereitstellen können.

Beide können betriebliche Veränderungen einführen. Sie wirken lediglich an unterschiedlichen Stellen im System.

Willisons Erfahrung ist besonders aufschlussreich, weil Ruffs erweiterte Regeln wie veröffentlicht funktionierten. Die Fehler erforderten weder ein beschädigtes Paket, noch ein kompromittiertes Registry oder einen fehlerhaften Installer.

Das Tool wurde erfolgreich installiert. Es prüfte das Projekt unter seiner neuen Richtlinie korrekt. Die CI scheiterte, weil diese Richtlinie von derjenigen abwich, auf die sich das Repository implizit verlassen hatte.

Damit handelt es sich um ein Reproduzierbarkeitsproblem. Ein reproduzierbarer Build oder Check sollte aus demselben Quellcode und denselben deklarierten Eingaben gleichwertige Ergebnisse erzeugen.

„Neueste Ruff-Version“ ist keine stabile Eingabe. Es ist eine bewegliche Anforderung, deren Bedeutung davon abhängt, wann ein Paketmanager sie auflöst.

Lockfiles und exakte Versionsbeschränkungen können diese Eingabe explizit machen. Renovierungsdienste können dann kontrollierte Upgrades vorschlagen, sodass Maintainer neue Diagnosen prüfen können, bevor sie die Versionsänderung zusammenführen.

Die Lehre reicht über Ruff hinaus. Formatter, Typprüfer, Test-Runner, Dokumentationsgeneratoren und Sicherheitsscanner können zwischen Releases allesamt ihre Standardwerte überarbeiten.

Ein Repository mit fixierten Anwendungsbibliotheken, aber frei beweglichen Entwicklungstools bleibt nur teilweise reproduzierbar. Sein Produktionsverhalten kann stabil bleiben, während sich sein Weg in die Produktion verändert.

Diese Sorge ist besonders für automatisierte Codierungssysteme relevant. Agenten führen häufig Repository-Prüfungen aus, interpretieren deren Ausgaben und ändern Code, bis jedes Gate bestanden ist.

Wenn sich die Tools hinter diesen Gates unerwartet ändern, steht der Agent vor einem beweglichen Ziel. Er kann unnötige Änderungen erzeugen oder Befunde unterdrücken, ohne zu verstehen, warum sie erschienen sind.

Teams, die eine durchsuchbare Engineering-Wissensdatenbank aufbauen, können Upgrade-Entscheidungen zusammen mit Konfiguration und CI-Historie bewahren. Dieser Kontext hilft künftigen Maintainern, beabsichtigte Richtlinien von unbeabsichtigtem Drift zu unterscheiden.

Simon Willison machte Ruffs neuen Zielkonflikt sichtbar

Ruffs umfassendere Standardwerte verbessern die Abdeckung beim ersten Einsatz, übertragen aber Migrationsarbeit auf Projekte, die eine ausgelassene Konfiguration als stabilen Vertrag behandelt haben.

Astrals Position ist eindeutig. Ruff sammelte Hunderte Prüfungen an, während seine Standardauswahl unverändert blieb, sodass schwerwiegende Diagnosen für nicht konfigurierte Nutzer inaktiv blieben.

Die alte Auswahl stammte aus Ruff v0.1.0. Seitdem wuchs der Regelkatalog um 260 Regeln, von 708 auf 968.

Wenn nur 59 Prüfungen aktiviert blieben, repräsentierte Ruffs Nutzung ohne Konfiguration einen immer kleineren Teil seiner Fähigkeiten. Neue Nutzer konnten annehmen, dass der Standard umfassender sei, als er tatsächlich war.

Das Release behebt diese Diskrepanz. Entwickler können nun Syntaxfehler, Laufzeitrisiken, Modernisierungsmöglichkeiten und verdächtige Konstrukte entdecken, ohne zuvor Hunderte Regelcodes studieren zu müssen.

Das ist für kleine Projekte wertvoll. Es nützt auch neuen Repositories, die eine sinnvolle Abdeckung wünschen, bevor Maintainer eine detaillierte Linting-Richtlinie entwickeln.

Die gegenteilige Erwartung ist ebenso nachvollziehbar. Standardwerte werden häufig als Produktverhalten behandelt, insbesondere wenn die Dokumentation ein Tool als ohne Konfiguration nutzbar darstellt.

Entwickler, die lint.select auslassen, können glauben, dass sie Ruffs gepflegte Grundlinie wählen. Vor Version 0.16.0 verließen sie sich zudem darauf, dass diese Grundlinie über Upgrades hinweg stabil bleibt.

Astral änderte die Grundlinie, weil es eigene Kosten gehabt hätte, sie unangetastet zu lassen. Projekte konnten Ruff bestehen, obwohl sie Fehler enthielten, die die installierte Binärdatei bereits erkennen konnte.

Der Zielkonflikt lautet daher nicht Sicherheit gegen Bequemlichkeit. Es geht um umfassenderen automatischen Schutz gegen Vorhersehbarkeit bei Upgrades.

Ein engerer Standard reduziert Überraschungen bei Upgrades, verbirgt aber mehr Befunde vor neuen Nutzern. Ein umfassenderer Standard deckt mehr Defekte auf, kann jedoch etablierte Pipelines stören.

Ruff v0.16.0 entscheidet sich für stärkeren Schutz beim nächsten Lauf. Projekte, die den früheren Vertrag wünschen, müssen diese Präferenz nun ausdrücklich festhalten.

Astral stellt eine direkte Kompatibilitätskonfiguration bereit:

Die genaue Tabelle kann abweichen, wenn die Konfiguration in einer eigenständigen ruff.toml liegt. Wichtig ist die explizite Regelauswahl, nicht der Dateiname.

Diese Einstellung stellt die früheren Standardregelfamilien wieder her. Sie verschafft Teams Zeit, ohne sie dazu zu zwingen, Version 0.15 auf unbestimmte Zeit festzuschreiben.

Die Wiederherstellung des alten Verhaltens sollte jedoch ein Migrationsschritt sein und keine automatische Ablehnung jeder neuen Prüfung. Einige Fehler können Bugs aufdecken, die sich sofort beheben lassen.

Ein sorgfältiges Upgrade beginnt damit, die vollständige Diagnoseausgabe zu erfassen. Maintainer können die Befunde dann nach Regelcode, Schweregrad, Sicherheit der Korrektur und Kompatibilitätsauswirkung gruppieren.

Regeln, die eindeutige Syntax- oder Laufzeitprobleme aufdecken, verdienen Priorität. Mechanische Modernisierungsbefunde können separat geprüft werden, vorzugsweise in fokussierten Commits.

Richtlinienorientierte Prüfungen erfordern die Einschätzung des Teams. Ein Muster kann für generierte Dateien, Framework-Konventionen, Kompatibilitätsmodule oder öffentliche APIs gültig sein, die sich nicht leichtfertig ändern lassen.

Ruff unterstützt für solche Fälle dateispezifische Ignorierungen und gezielte Unterdrückungen. Version 0.16.0 ergänzt ruff: ignore und ruff: file-ignore-Kommentare neben dem bestehenden noqa-Verhalten.

Gezielte Unterdrückung lässt sich normalerweise leichter prüfen als ein breit gefasster Ausschluss. Sie dokumentiert, wo eine Regel nicht passt, und kann einen Grund für künftige Maintainer enthalten.

Dennoch können Unterdrückungen unübersichtlich werden, wenn auf einmal Hunderte bestehender Verstöße erscheinen. Eine projektweite Regelauswahl kann ehrlicher sein, bis Maintainer eine bewusste Bereinigung planen.

Die richtige Reaktion hängt von der Reife des Repositories ab. Ein neues Projekt kann die umfassendere Grundlinie sofort akzeptieren, während eine große Legacy-Codebasis möglicherweise eine schrittweise Einführung benötigt.

Deshalb haben Änderungen an Standardwerten ein ungewöhnliches Gewicht. Sie wenden eine Produktentscheidung auf Projekte mit grundverschiedenen Historien und Einschränkungen an.

Die neuen Standardwerte sind nur ein Teil der Migration

Teams, die die erste Welle von Diagnosen beheben, müssen weiterhin Markdown-Formatierung, maschinenlesbare Ausgabe und das Verhalten von Unterdrückungen prüfen.

Ruff v0.16.0 erweitert den normalen Geltungsbereich seines Formatters auf Python-Codeblöcke in Markdown. Das kann READMEs, Dokumentationsseiten und notebookähnliche Veröffentlichungsdateien verändern.

Der Formatter erkennt gängige Python-Informationsstrings an abgegrenzten Codeblöcken. Er behandelt pyi als Stub-Code und pycon als interaktive Python-Sitzung.

Quarto-Nutzer können auch Blöcke formatieren, die mit Formen wie {python} markiert sind. Projekte mit .qmd-Dateien benötigen möglicherweise eine Erweiterungszuordnung, bevor Ruff sie einbezieht.

Diese Funktion richtet Dokumentationsbeispiele am Formatter für den Quellcode aus. Das senkt die Wahrscheinlichkeit, dass kopierte Beispiele veraltete oder uneinheitliche Formatierungen verwenden.

Sie kann auch unerwartete CI-Fehler verursachen, wenn ruff format --check zuvor nur herkömmliche Quelldateien geprüft hat. Verantwortliche für die Dokumentation könnten erstmals mit Ruff-Richtlinien konfrontiert werden.

Projekte können Markdown bei Bedarf mit extend-exclude ausschließen. Sie können zudem Kommentare zur Unterdrückung der Formatierung um ausgewählte Bereiche verwenden.

Die Entscheidung sollte davon abhängen, ob Codebeispiele ausführbare Anleitung oder bewusst angeordnetes Erklärungsmaterial sind. Automatische Formatierung unterstützt die erste Kategorie konsistenter als die zweite.

Auch die Darstellung von Diagnosen hat sich geändert. Ruff zeigt vorgeschlagene Diffs nun innerhalb der normalen Ausgabe von check und format --check.

Zuvor konnten Entwickler einen Diff separat anfordern. Die neue vollständige Ausgabe hält Diagnosen und vorgeschlagene Änderungen zusammen, wodurch sich ein fehlgeschlagener Check leichter interpretieren lässt.

Für CI-Anbieter unterstützt format --check nun Ausgabeformate für GitHub- und GitLab-Anmerkungen. Ein Formatierungsproblem kann direkt an der betroffenen Zeile in einer Code-Review erscheinen.

Maschinelle Verbraucher benötigen mehr Aufmerksamkeit. Mehrere Felder in Ruffs JSON-Ausgabe können nun null sein, statt Platzhalterpositionen zu enthalten.

Zu den betroffenen Feldern gehören filename, location, end_location sowie entsprechende Positionen innerhalb von Fix-Änderungen. Verbraucher, die davon ausgehen, dass jede Position ein Objekt oder String ist, können fehlschlagen.

Für die meisten Nutzer ist dies eine kleine Breaking Change. Wichtiger ist sie für Teams, die Ruff-Ausgaben in Dashboards, Review-Bots oder eigene Qualitätssysteme einlesen.

Eine Pipeline kann nach dem Update daher auf drei Ebenen fehlschlagen. Ruff kann eine neue Verletzung finden, die Formatierung kann auf einen neuen Dateityp ausgeweitet werden, oder ein Ausgabeparser kann nullable Felder ablehnen.

Jeden Fehler als „mehr Lint-Regeln“ zu behandeln, birgt das Risiko, die eigentliche Ursache zu übersehen. Verantwortliche sollten vor der Bearbeitung von Anwendungscode feststellen, welche Ebene sich geändert hat.

Auch das neue Unterdrückungsformat verdient eine Richtlinienprüfung. Ein zeilenabschließendes ruff: ignore[F401] verhält sich für diese Diagnose wie ein gezieltes noqa.

Ein vorangestellter Kommentar kann Befunde in der nächsten logischen Zeile unterdrücken. Das ist bei mehrzeiligen Funktionsköpfen nützlich, wenn das gemeldete Problem nicht sauber neben das relevante Token passt.

Eine dateiweite Unterdrückung ist über ruff: file-ignore verfügbar. Sie kann einen Grund enthalten, der Reviewern mehr Informationen bietet als ein unerklärter pauschaler Ausschluss.

Die neue Option --add-ignore kann automatisch eine Unterdrückung einfügen. Dieser Komfort sollte nicht die Prüfung ersetzen, ob die zugrunde liegende Diagnose einen echten Defekt darstellt.

Automatisierung kann CI schnell wieder grün machen, indem sie Kommentare hinzufügt. Sie kann nicht entscheiden, ob ein Projekt diese Ausnahme über Jahre hinweg tragen sollte.

Ruff unterscheidet zwischen als sicher geltenden Fixes und solchen, die eine Unsafe-Fix-Option erfordern. Selbst eine sichere Klassifizierung sollte im Kontext von generiertem Code, öffentlichen APIs und ungewöhnlichem Laufzeitverhalten überprüft werden.

Pythons dynamisches Verhalten begrenzt, was statische Analyse garantieren kann. Ruffs eigene Fix-Hinweise bitten Nutzer, Fälle zu melden, in denen ein sicherer Fix Code beschädigt.

Diese Einschränkung schwächt nicht das Argument für Linting. Sie unterstreicht die Notwendigkeit, zwischen Erkennung, automatisierter Änderung und menschlicher Freigabe zu unterscheiden.

Nicht angeheftete Entwicklertools sind jetzt der kritische Punkt

Der unmittelbare Druck liegt auf Repositories, die Ruff dynamisch installieren und die Regelauswahl implizit lassen.

Eine vollständig angeheftete Ruff-Version mit einer expliziten select-Liste verfügt über zwei stabile Kontrollmechanismen. Einer fixiert die Tool-Implementierung, der andere die vom Projekt gewählte Lint-Richtlinie.

Eine frei bewegliche Version mit expliziten Regeln bietet teilweise Stabilität. Neue Ruff-Releases können weiterhin das Verhalten einzelner Regeln, Parsing, Ausgabe, Formatierung oder die Semantik der Konfiguration verändern.

Auch eine angeheftete Version ohne explizite Regeln bietet nur teilweise Stabilität. Die CI bleibt konsistent, bis Verantwortliche Ruff aktualisieren und die Standardmigration auf einmal eintrifft.

Eine nicht angeheftete Version ohne explizite Regeln hat keine der beiden Kontrollen. Diese Kombination schuf die Bedingungen hinter Simon Willisons Ruff-CI-Fehlern.

Anheften bedeutet nicht, das Tool auf unbestimmte Zeit einzufrieren. Es trennt das Entdecken eines Upgrades von dessen Übernahme.

Ein Pull Request für ein Abhängigkeitsupdate schafft eine sichtbare Grenze für die Review. Die CI kann die neuen Befunde zeigen, während der bestehende Main-Branch reproduzierbar bleibt.

Verantwortliche können dann zwischen mehreren Reaktionen wählen:

• Eindeutige Defekte beheben, die durch die neuen Standardwerte erkannt wurden.

• Sichere mechanische Änderungen in isolierten Commits akzeptieren.

• Bewusste Ausnahmen für repositoriespezifische Muster konfigurieren.

• Die frühere Auswahl wiederherstellen und eine schrittweise Regelübernahme planen.

• Parser aktualisieren, die nullable JSON-Positionen nicht verarbeiten können.

• Dokumentationsdateien ausschließen, deren manuelle Formatierung erhalten bleiben muss.

Diese Maßnahmen sollten nicht blind vermischt werden. Ein einzelner großer Autofix-Commit kann Verhaltensänderungen zwischen Tausenden von Formatierungsänderungen verbergen.

Eine Gruppierung nach Regelfamilien sorgt für klarere Reviews. Sie erleichtert auch Rollbacks, wenn eine Regel mit den unterstützten Python-Versionen des Projekts kollidiert.

Die Zielversionskonfiguration ist wichtig, wenn pyupgrade-Regeln aktiv sind. Moderne Syntax kann für eine Interpreter-Basislinie korrekt und für eine andere unbrauchbar sein.

Teams sollten prüfen, ob Ruffs konfiguriertes Python-Ziel der Realität der Bereitstellung entspricht. Andernfalls können Modernisierungshinweise der Produktionsunterstützung vorauslaufen.

Auch generierter Code benötigt eine separate Behandlung. Das Neuformatieren oder Linten generierter Dateien erzeugt oft Änderungen, die beim nächsten Lauf des Generators wieder verschwinden.

Generierte Pfade auszuschließen, kann genauer sein, als sie mit Unterdrückungskommentaren zu füllen. Die Quelle oder Vorlage des Generators ist in der Regel der richtige Ort, um Qualität durchzusetzen.

Monorepositories stehen vor einer weiteren Komplikation. Unterschiedliche Pakete können verschiedene Python-Versionen unterstützen oder eigene Lint-Richtlinien pflegen.

Ein Standard auf Root-Ebene kann die Abläufe vereinfachen, aber auch einen Migrationszeitplan auf nicht zusammenhängende Komponenten übertragen. Eine Konfiguration pro Paket kann die Verantwortlichkeiten besser abbilden.

Die zentrale skeptische Frage lautet, ob 413 Regeln eine breit akzeptable Basislinie bilden. Astral hat die Auswahl dokumentiert, doch die Akzeptanz in der Praxis wird ihre False-Positive-Rate und den Kompatibilitätsaufwand testen.

Willisons Fehler liefern ein frühes Signal, aber keine repräsentative Umfrage. Sie zeigen, dass Störungen möglich sind, nicht dass die meisten Ruff-Nutzer sie erleben werden.

Projekte, die bereits ein explizites select oder extend-select verwenden, können anders reagieren. Ihre effektive Regelmenge hängt davon ab, wie diese Konfiguration mit der neuen Basislinie interagiert.

Astral sagt, dass die Änderung auch für konfigurierte Nutzer hilfreiche Regeln sichtbar machen kann. Jedes Team sollte die aufgelöste Auswahl prüfen, statt anzunehmen, die Konfiguration mache das Release irrelevant.

Es besteht auch das Risiko einer Überkorrektur. Ruff anzuheften, während jedes andere Entwicklertool frei beweglich bleibt, löst nur eine sichtbare Instanz eines umfassenderen Problems.

Teams sollten Formatter, Typprüfer, Testtools, Pre-Commit-Hooks und Dokumentations-Builder inventarisieren. Jedes davon kann einen sauberen Build in einen Fehlschlag verwandeln.

Die dauerhafte Richtlinie ist einfach: Versioniere die Umgebung, die entscheidet, ob Code ausgeliefert werden darf. Diese Richtlinie umfasst auch die Tools, die Entwickler traditionell als optional einstufen.

Worauf Simon Willison und Ruff-Nutzer als Nächstes achten sollten

Die nächsten drei Signale werden zeigen, ob Ruffs breitere Basislinie zur akzeptierten Richtlinie wird oder zu einer wiederkehrenden Quelle von CI-Reibung.

Das erste Signal ist Astrals Aktivität bei Patch-Releases in den Wochen nach Version 0.16.0. Rasche Anpassungen an Standardregeln würden darauf hindeuten, dass reale Repositories erhebliche Kompatibilitätsprobleme aufgedeckt haben.

Regelspezifische Korrekturen würden die erweiterte Basislinie nicht entkräften. Sie würden zeigen, dass eine deutlich größere Auswahl unter Produktionslasten nachjustiert werden muss.

Umgekehrt würde eine begrenzte Rollback-Aktivität Astrals Argument stärken, dass die meisten neuen Diagnosen umsetzbar sind. Sie würde zudem mehr Projekte dazu ermutigen, die Standardwerte zu akzeptieren, statt die frühere Auswahl wiederherzustellen.

Das zweite Signal ist das Konfigurationsverhalten in öffentlichen Python-Repositories. Verantwortliche werden ihre Einschätzung durch Commits offenlegen, auch ohne formelle Umfragen.

Eine Welle expliziter Auswahlen der alten Standardwerte würde darauf hindeuten, dass Teams Migrationskontrolle höher bewerten als sofortige Abdeckung. Weit verbreitete Fixes und beibehaltene Standardwerte würden auf eine erfolgreiche Übernahme hindeuten.

Die aussagekräftigsten Repositories werden ihre Begründung dokumentieren. Eine bloße Ignore-Liste zeigt, was sich geändert hat, während eine Migrationsnotiz erklärt, warum ein Team jede Regelfamilie akzeptiert oder abgelehnt hat.

Das dritte Signal ist, ob Paketvorlagen und CI-Beispiele beginnen, Ruff anzuheften. Generatoren für neue Projekte prägen Gewohnheiten oft wirksamer als nachträgliche Warnungen.

Wenn Vorlagen Versionsbeschränkungen und automatisierte Update-Workflows übernehmen, wird Willisons Erfahrung die Praxis über dieses einzelne Release hinaus beeinflusst haben.

Wenn Beispiele weiterhin ein unbeschränktes ruff installieren, können künftige Standard- oder Formatter-Änderungen dieselbe Überraschung wiederholen. Die konkrete Regelanzahl wird sich unterscheiden, doch das Reproduzierbarkeitsproblem bleibt bestehen.

Entwickler müssen nicht auf diese Signale warten, bevor sie handeln. Sie können die neue Version gegen einen Branch ausführen, die Ausgabe bewahren und entscheiden, welche Befunde ihren Code verbessern.

Ein nützlicher Testbefehl ist:

Die Angabe der Version macht das Experiment wiederholbar. Die separate Ausführung von ruff format --check . hilft dabei, Lint-Fehler von Änderungen an Markdown oder der Quellcodeformatierung zu unterscheiden.

Beginnen Sie nicht mit dem Hinzufügen globaler Ignorierungen. Stellen Sie zuerst fest, welche Regeln eindeutige Bugs gefunden haben, welche Modernisierung vorschlagen und welche eine diskutierbare Richtlinie kodieren.

Halten Sie die Entscheidung anschließend in Konfiguration und Versionskontrolle fest. Ein grünes CI-Badge ist weniger wertvoll, wenn niemand weiß, welcher Qualitätsvertrag es hervorgebracht hat.

Ruff v0.16.0 zeigt den Vorteil und die Kosten aktiver Standardwerte. Das Tool findet ohne Konfiguration mehr, doch ausgelassene Konfiguration bedeutet nicht mehr unverändertes Verhalten.

Simon Willisons Erfahrung macht aus diesem abstrakten Zielkonflikt eine unmittelbare Engineering-Frage: Erklärt Ihr Repository die Tools und Richtlinien, die seine Releases steuern?

Führen Sie die angeheftete Version auf einem Branch aus, prüfen Sie jede neue Regelfamilie und machen Sie die Basislinie explizit. Der nächste saubere Build sollte eine geprüfte Entscheidung widerspiegeln, nicht das Datum, an dem die CI zufällig Ruff installiert hat.