Simon Willison napotkał błędy CI po Ruff v0.16.0. Zmieniły się ustawienia domyślne

Simon Willison zauważył, że kilka zadań CI kończy się błędem po tym, jak Ruff v0.16.0 rozszerzył domyślny zestaw reguł lintingu z 59 do 413. Nieprzypięta zależność deweloperska Ruff po cichu pobrała nowe wydanie do istniejących projektów Python.

Astral wydał tę wersję 23 lipca 2026 roku. Dwa dni później Willison opisał, jak aktualizacja trafiła do jego buildów bez celowego uaktualnienia. Błędy przekształciły wydanie lintera w praktyczne ostrzeżenie dotyczące zarządzania zależnościami.

Główny konflikt nie dotyczy bardziej rygorystycznego lintingu kontra słabszego kodu. Chodzi o poprawiające się bezpieczeństwo Ruff bez konfiguracji oraz stabilność, której deweloperzy oczekują od niezmienionych repozytoriów. To napięcie ma znaczenie wszędzie tam, gdzie CI przy każdym uruchomieniu instaluje najnowsze dostępne narzędzia deweloperskie.

Ruff v0.16.0 zmienił znaczenie słowa „domyślne”

Najważniejszą zmianą w Ruff v0.16.0 nie jest nowe polecenie. To znacznie szersza definicja tego, co projekty bez konfiguracji powinny uznawać za błąd.

Ruff to linter i formatter dla Pythona napisany w Rust. Linter analizuje kod źródłowy pod kątem błędów, podejrzanych wzorców i wybranych problemów stylistycznych bez uruchamiania programu.

Przed tym wydaniem Ruff włączał 59 reguł, gdy projekt nie określał jawnego wyboru reguł lintingu. Wersja 0.16.0 włącza w tych samych warunkach 413 reguł, zgodnie z przewodnikiem migracji Astral.

Oznacza to wzrost o 354 aktywne kontrole. Oznacza to również, że domyślna instalacja Ruff ocenia teraz prawie siedem razy więcej reguł niż wcześniej.

Rozrósł się także cały katalog. Gdy ustawienia domyślne Ruff ostatnio zmieniono w wersji 0.1.0, narzędzie obsługiwało 708 reguł. Astral podaje, że obecny zbiór zawiera 968 reguł.

Stare ustawienia domyślne wybierały przede wszystkim część reguł Pyflakes i pycodestyle. Projekty mogły wdrożyć Ruff bez natychmiastowego podejmowania szczegółowych decyzji dotyczących wielu zintegrowanych rodzin reguł.

Ta zachowawcza baza ułatwiała dopasowanie Ruff do istniejących repozytoriów. Tworzyła jednak również coraz większą lukę między tym, co narzędzie potrafiło wykryć, a tym, co zgłaszało automatycznie.

Astral znacząco zmniejszył tę lukę w wersji 0.16.0. Nowe ustawienia domyślne czerpią z dodatkowych rodzin, w tym flake8-bugbear, pyupgrade oraz własnej kategorii RUF Ruff.

Flake8-bugbear koncentruje się na prawdopodobnych błędach i wątpliwych wzorcach projektowych. Pyupgrade wskazuje składnię i wzorce biblioteki standardowej, które można unowocześnić dla obsługiwanej przez projekt wersji Pythona.

Domyślna lista reguł obejmuje teraz kontrole, które mogą ujawniać problemy ze składnią i natychmiastowe błędy wykonania. Nie są to wyłącznie preferencje dotyczące odstępów czy nazewnictwa.

To rozróżnienie wyjaśnia, dlaczego błędy Ruff w CI mogą zasługiwać na uwagę. Część nowych zgłoszeń ujawnia wady, które wcześniej przechodziły tylko dlatego, że Ruff nie włączał automatycznie odpowiedniego detektora.

Inne zgłoszenia będą dotyczyć utrzymywalności, modernizacji albo wzorców, które zespół świadomie akceptuje. Większy domyślny zestaw nie może znać wymagań kompatybilności ani konwencji projektowych każdego repozytorium.

Ruff v0.16.0 zmienia więc jednocześnie dwie rzeczy. Zwiększa automatyczne wykrywanie defektów i przenosi więcej decyzji dotyczących polityki na pierwszą aktualizację po 23 lipca.

Wydanie domyślnie formatuje też bloki kodu Python wewnątrz plików Markdown. Obsługiwane bloki ogrodzone obejmują python, py, python3, py3, pyi oraz pycon.

To zachowanie ma znaczenie dla repozytoriów zawierających dokumentację, samouczki lub notatniki Quarto. Kontrola formatowania może teraz wskazywać zmiany poza konwencjonalnymi plikami .py.

Informacje o wydaniu Ruff opisują także nowe komentarze wyciszające oraz bogatsze dane diagnostyczne. Te usprawnienia pomagają deweloperom obsługiwać dodatkowe ustalenia, gdy się pojawią.

Zmiana zakresu pozostaje głównym wydarzeniem migracyjnym. Polecenie, które w zeszłym tygodniu działało przewidywalnie, może dziś zwrócić niezerowy kod wyjścia dla identycznego kodu źródłowego.

Dlaczego błędy CI Simona Willisona mają znaczenie

Doświadczenie Simona Willisona pokazuje, jak aktualizacja narzędzia deweloperskiego może zmienić faktyczną politykę repozytorium bez zmiany samego repozytorium.

Willison jest niezależnym deweloperem i autorem znanym z projektów związanych z Pythonem, narzędziami danych i generatywną AI. Wcześniej współtworzył również framework webowy Django.

25 lipca Willison napisał, że jego „różne zadania CI” zaczęły kończyć się błędem. Prześledził problem do nowych ustawień domyślnych Ruff i nieprzypiętej zależności deweloperskiej "ruff".

Jego relacja o Ruff nadaje wydaniu konkretną perspektywę użytkownika. Kod repozytorium nie musiał ulec regresji, ale środowisko jego walidacji zmieniło się pod nim.

Zadanie CI, czyli zadanie ciągłej integracji, uruchamia zautomatyzowane kontrole, gdy deweloperzy proponują lub scalają zmiany. Zespoły polegają na spójnych wynikach, aby zdecydować, czy kod można bezpiecznie zaakceptować.

Jeżeli zadanie instaluje ruff bez ograniczenia wersji, mechanizm rozwiązywania zależności może wybrać najnowsze dostępne wydanie. Kolejny build może wtedy egzekwować zachowanie, którego żaden opiekun projektu wyraźnie nie przejrzał.

Ten tryb awarii łatwo zbagatelizować, ponieważ Ruff jest zwykle zależnością deweloperską. Zazwyczaj nie trafia do aplikacji obsługującej użytkowników.

Mimo to zależności deweloperskie kontrolują, czy oprogramowanie może przejść przez pipeline dostarczania. Nowy kod wyjścia lintera może zablokować pull request, zatrzymać wydanie lub pochłonąć godziny dochodzenia.

Incydent ujawnia również mylące rozróżnienie między zależnościami wykonawczymi a narzędziami. Pakiety wykonawcze wpływają na działanie wdrożonego oprogramowania, natomiast narzędzia wpływają na to, czy deweloperzy w ogóle mogą je wdrożyć.

Oba rodzaje mogą wprowadzać zmiany operacyjne. Po prostu działają w różnych punktach systemu.

Doświadczenie Willisona jest szczególnie użyteczne, ponieważ rozszerzone reguły Ruff działały zgodnie z wydaniem. Błędy nie wymagały uszkodzonego pakietu, naruszonego rejestru ani wadliwego instalatora.

Narzędzie zainstalowało się pomyślnie. Poprawnie przeanalizowało projekt zgodnie z nową polityką. CI zakończyło się błędem, ponieważ ta polityka różniła się od tej, na której repozytorium domyślnie polegało.

To czyni ten przypadek problemem odtwarzalności. Odtwarzalny build lub kontrola powinny dawać równoważne wyniki dla tego samego kodu źródłowego i zadeklarowanych danych wejściowych.

„Najnowszy Ruff” nie jest stabilnym wejściem. To ruchome żądanie, którego znaczenie zależy od momentu, w którym menedżer pakietów rozwiązuje zależności.

Pliki lockfile i dokładne ograniczenia mogą uczynić to wejście jawnym. Usługi automatyzujące aktualizacje mogą następnie proponować kontrolowane uaktualnienia, pozwalając opiekunom przejrzeć nowe diagnostyki przed scaleniem zmiany wersji.

Lekcja wykracza poza Ruff. Formatery, narzędzia do sprawdzania typów, wykonawcy testów, generatory dokumentacji i skanery bezpieczeństwa mogą między wydaniami zmieniać ustawienia domyślne.

Repozytorium z przypiętymi bibliotekami aplikacji, ale pływającymi narzędziami deweloperskimi, pozostaje tylko częściowo odtwarzalne. Jego zachowanie produkcyjne może pozostać niezmienne, podczas gdy ścieżka do produkcji się zmienia.

Ta kwestia jest szczególnie istotna dla zautomatyzowanych systemów programistycznych. Agenci często uruchamiają kontrole repozytorium, interpretują ich wyniki i modyfikują kod, aż przejdą wszystkie bramki.

Jeśli narzędzia stojące za tymi bramkami zmieniają się nieoczekiwanie, agent staje przed ruchomym celem. Może generować niepotrzebne zmiany lub wyciszać ustalenia bez zrozumienia, dlaczego się pojawiły.

Zespoły budujące przeszukiwalną bazę wiedzy inżynierskiej mogą zachowywać decyzje dotyczące aktualizacji wraz z konfiguracją i historią CI. Ten kontekst pomaga przyszłym opiekunom odróżniać zamierzoną politykę od przypadkowego dryfu.

Simon Willison ujawnił nowy kompromis Ruff

Szersze ustawienia domyślne Ruff poprawiają pokrycie przy pierwszym uruchomieniu, ale przenoszą pracę migracyjną na projekty, które traktowały brak konfiguracji jako stabilny kontrakt.

Stanowisko Astral jest proste. Ruff zgromadził setki kontroli, podczas gdy jego domyślny wybór pozostawał zamrożony, pozostawiając poważne diagnostyki nieaktywne dla użytkowników bez konfiguracji.

Stary wybór pochodził z Ruff v0.1.0. Od tego czasu katalog reguł zwiększył się o 260 — z 708 do 968.

Utrzymanie tylko 59 włączonych kontroli oznaczało, że działanie Ruff bez konfiguracji reprezentowało coraz mniejszą część jego możliwości. Nowi użytkownicy mogli zakładać, że ustawienia domyślne są bardziej kompleksowe, niż było w rzeczywistości.

Wydanie rozwiązuje tę niezgodność. Deweloperzy mogą teraz odkrywać błędy składniowe, zagrożenia wykonawcze, możliwości modernizacji i podejrzane konstrukcje bez wcześniejszego studiowania setek kodów reguł.

To jest wartościowe dla małych projektów. Korzystają na tym również nowe repozytoria, które chcą rozsądnego pokrycia, zanim opiekunowie opracują szczegółową politykę lintingu.

Przeciwne oczekiwanie jest równie uzasadnione. Ustawienia domyślne są często traktowane jako zachowanie produktu, zwłaszcza gdy dokumentacja przedstawia narzędzie jako użyteczne bez konfiguracji.

Deweloperzy, którzy pomijają lint.select, mogą uważać, że wybierają utrzymywaną bazę Ruff. Przed wersją 0.16.0 polegali też na tym, że ta baza pozostanie stabilna między aktualizacjami.

Astral zmienił tę bazę, ponieważ pozostawienie jej bez zmian niosło własny koszt. Projekty mogły przechodzić Ruff, mimo że zawierały błędy, które zainstalowany binarny program już potrafił wykryć.

Kompromis nie dotyczy zatem bezpieczeństwa kontra wygody. Chodzi o szerszą automatyczną ochronę kontra przewidywalność aktualizacji.

Węższe ustawienia domyślne ograniczają zaskoczenie podczas aktualizacji, ale ukrywają więcej ustaleń przed nowymi użytkownikami. Szersze ustawienia ujawniają więcej defektów, lecz mogą zakłócać ustalone pipeline’y.

Ruff v0.16.0 wybiera silniejszą ochronę przy kolejnym uruchomieniu. Projekty, które chcą zachować wcześniejszy kontrakt, muszą teraz wyraźnie zapisać tę preferencję.

Astral udostępnia bezpośrednią konfigurację kompatybilności:

Dokładna tabela może się różnić, gdy konfiguracja znajduje się w osobnym ruff.toml. Ważna jest jawna selekcja reguł, a nie nazwa pliku.

To ustawienie przywraca wcześniejsze domyślne rodziny. Daje zespołom czas na reakcję, nie zmuszając ich do przypinania wersji 0.15 na czas nieokreślony.

Przywrócenie starego zachowania powinno jednak być krokiem migracyjnym, a nie automatycznym odrzuceniem każdej nowej kontroli. Niektóre błędy mogą wskazywać problemy, które warto natychmiast naprawić.

Ostrożna aktualizacja zaczyna się od zebrania pełnego wyniku diagnostycznego. Opiekunowie mogą następnie grupować ustalenia według kodu reguły, ważności, bezpieczeństwa poprawki i wpływu na kompatybilność.

Reguły ujawniające jednoznaczne problemy składniowe lub wykonawcze zasługują na priorytet. Ustalenia dotyczące mechanicznej modernizacji można przeglądać osobno, najlepiej w skoncentrowanych commitach.

Kontrole zorientowane na politykę wymagają osądu zespołu. Dany wzorzec może być prawidłowy dla plików generowanych, konwencji frameworka, modułów kompatybilności albo publicznych API, których nie można swobodnie zmieniać.

Ruff obsługuje ignorowanie reguł dla poszczególnych plików i ukierunkowane wyciszenia w takich przypadkach. Wersja 0.16.0 dodaje komentarze ruff: ignore i ruff: file-ignore obok istniejącego zachowania noqa.

Ukierunkowane wyciszenie jest zwykle łatwiejsze do audytu niż szerokie wykluczenie. Rejestruje miejsca, w których reguła nie pasuje, i może zawierać uzasadnienie dla przyszłych opiekunów.

Wyciszenia mogą jednak stać się bałaganem, gdy jednocześnie pojawiają się setki istniejących naruszeń. Wybór reguł dla całego projektu może być uczciwszy, dopóki opiekunowie nie zaplanują świadomego porządkowania.

Właściwa odpowiedź zależy od dojrzałości repozytorium. Nowy projekt może od razu przyjąć szerszą bazę, podczas gdy duża starsza baza kodu może wymagać etapowego wdrożenia.

Właśnie dlatego zmiany ustawień domyślnych mają nietypową wagę. Stosują jeden osąd na poziomie produktu do projektów o radykalnie odmiennych historiach i ograniczeniach.

Nowe ustawienia domyślne to tylko część migracji

Zespoły, które naprawią pierwszą falę diagnostyki, nadal muszą przejrzeć formatowanie Markdown, dane wyjściowe do odczytu maszynowego oraz zachowanie mechanizmów wyciszania.

Ruff v0.16.0 rozszerza zwykły zasięg swojego formatera na bloki kodu Python w Markdown. Może to zmienić pliki README, strony dokumentacji i pliki publikacyjne przypominające notatniki.

Formater rozpoznaje popularne identyfikatory języka Python przypisane do ogrodzonych bloków kodu. Traktuje pyi jako kod stubów, a pycon jako interaktywną sesję Pythona.

Użytkownicy Quarto mogą także formatować bloki oznaczone formami takimi jak {python}. Projekty korzystające z plików .qmd mogą potrzebować mapowania rozszerzeń, zanim Ruff je uwzględni.

Ta funkcja ujednolica przykłady w dokumentacji z formatowaniem kodu źródłowego. Zmniejsza to ryzyko, że kopiowane przykłady będą używać nieaktualnego lub niespójnego formatowania.

Może jednak spowodować nieoczekiwane awarie CI, gdy ruff format --check wcześniej sprawdzał tylko konwencjonalne pliki źródłowe. Osoby odpowiedzialne za dokumentację mogą po raz pierwszy zetknąć się z polityką Ruffa.

W razie potrzeby projekty mogą wykluczyć Markdown za pomocą extend-exclude. Mogą też używać komentarzy wyłączających formatowanie wokół wybranych fragmentów.

Decyzja powinna zależeć od tego, czy próbki kodu są wykonywalnymi wskazówkami, czy starannie ułożonym materiałem objaśniającym. Automatyczne formatowanie pomaga pierwszej kategorii bardziej konsekwentnie niż drugiej.

Zmieniło się również renderowanie diagnostyki. Ruff pokazuje teraz sugerowane różnice w zwykłym wyjściu check i format --check.

Wcześniej programiści mogli osobno zażądać różnic. Nowe pełne wyjście łączy diagnostykę z proponowanymi zmianami, dzięki czemu nieudane sprawdzenie jest łatwiejsze do zinterpretowania.

Dla dostawców CI format --check obsługuje teraz formaty wyjściowe używane przez adnotacje GitHub i GitLab. Problem z formatowaniem może pojawić się bezpośrednio przy dotkniętej nim linii w przeglądzie kodu.

Odbiorcy maszynowi wymagają większej uwagi. Kilka pól w wyjściu JSON Ruffa może teraz mieć wartość null, zamiast zawierać zastępcze lokalizacje.

Dotyczy to pól filename, location, end_location oraz odpowiadających im lokalizacji w edycjach poprawek. Odbiorcy zakładający, że każda lokalizacja jest obiektem lub ciągiem znaków, mogą przestać działać.

Dla większości użytkowników jest to niewielka zmiana powodująca niezgodność. Ma większe znaczenie dla zespołów, które przetwarzają wyjście Ruffa do pulpitów, botów przeglądu kodu lub własnych systemów jakości.

Po aktualizacji potok może więc zawieść na trzech poziomach. Ruff może znaleźć nowe naruszenie, formatowanie może objąć nowy typ pliku albo parser wyjścia może odrzucić pola dopuszczające wartość null.

Traktowanie każdego błędu jako „większej liczby reguł lintowania” grozi przeoczeniem rzeczywistej przyczyny. Opiekunowie projektu powinni ustalić, która warstwa się zmieniła, zanim zaczną edytować kod aplikacji.

Nowy format wyciszania także zasługuje na przegląd polityki. ruff: ignore[F401] na końcu linii działa jak ukierunkowane noqa dla tej diagnostyki.

Komentarz poprzedzający może wyciszyć zgłoszenia w następnej logicznej linii. Jest to przydatne dla wieloliniowych nagłówków funkcji, gdy raportowany problem nie mieści się wygodnie obok odpowiedniego tokenu.

Wyciszenie dla całego pliku jest dostępne przez ruff: file-ignore. Może zawierać uzasadnienie, co daje osobom dokonującym przeglądu więcej informacji niż niewyjaśnione, ogólne wykluczenie.

Nowa opcja --add-ignore może automatycznie wstawić wyciszenie. Ta wygoda nie powinna zastępować oceny, czy stojąca za nią diagnostyka wskazuje rzeczywistą wadę.

Automatyzacja może szybko zazielenić CI przez dodanie komentarzy. Nie potrafi jednak zdecydować, czy projekt powinien utrzymywać taki wyjątek przez lata.

Ruff rozdziela poprawki uznawane za bezpieczne od tych wymagających opcji niebezpiecznych poprawek. Nawet klasyfikację jako bezpieczna należy przeanalizować w kontekście generowanego kodu, publicznych API i nietypowego zachowania w czasie działania.

Dynamiczna natura Pythona ogranicza to, co analiza statyczna może zagwarantować. Własne wytyczne dotyczące poprawek Ruffa proszą użytkowników o zgłaszanie przypadków, w których bezpieczna poprawka uszkadza kod.

Ograniczenie to nie osłabia argumentów za lintowaniem. Wzmacnia potrzebę rozróżnienia między wykrywaniem, automatyczną modyfikacją a ludzką akceptacją.

Nieprzypięte narzędzia deweloperskie są teraz newralgicznym punktem

Natychmiastowa presja dotyka repozytoria, które instalują Ruffa dynamicznie, pozostawiając wybór reguł domyślnym ustawieniom.

W pełni przypięta wersja Ruffa z jawną listą select ma dwa stabilne mechanizmy kontroli. Jeden ustala implementację narzędzia, drugi — wybraną przez projekt politykę lintowania.

Wersja zmienna z jawnymi regułami ma częściową stabilność. Nowe wydania Ruffa mogą nadal zmieniać zachowanie poszczególnych reguł, parsowanie, dane wyjściowe, formatowanie lub semantykę konfiguracji.

Przypięta wersja bez jawnych reguł również ma częściową stabilność. CI pozostaje spójne, dopóki opiekunowie nie zaktualizują Ruffa — wtedy migracja ustawień domyślnych nadchodzi jednocześnie.

Nieprzypięta wersja bez jawnych reguł nie ma żadnego z tych mechanizmów kontroli. To połączenie stworzyło warunki stojące za awariami CI Ruffa u Simona Willisona.

Przypięcie nie oznacza zamrożenia narzędzia na czas nieokreślony. Oddziela wykrycie aktualizacji od jej przyjęcia.

Żądanie pull request aktualizujące zależność tworzy widoczną granicę przeglądu. CI może pokazać nowe zgłoszenia, podczas gdy istniejąca gałąź główna pozostaje odtwarzalna.

Opiekunowie mogą wtedy wybrać spośród kilku reakcji:

• Naprawić oczywiste wady wskazane przez nowe ustawienia domyślne.

• Zaakceptować bezpieczne mechaniczne zmiany w odizolowanych commitach.

• Skonfigurować zamierzone wyjątki dla wzorców specyficznych dla repozytorium.

• Przywrócić wcześniejszy wybór i zaplanować etapowe wdrożenie reguł.

• Zaktualizować parsery, które nie obsługują lokalizacji JSON dopuszczających wartość null.

• Wykluczyć pliki dokumentacji, które muszą zachować ręczne formatowanie.

Działania te nie powinny być bezrefleksyjnie łączone. Jeden duży commit z automatycznymi poprawkami może ukryć zmiany zachowania wśród tysięcy edycji formatowania.

Grupowanie pracy według rodzin reguł pozwala uzyskać czytelniejszy przegląd. Ułatwia również wycofanie zmian, jeśli jedna reguła koliduje z wersjami Pythona obsługiwanymi przez projekt.

Konfiguracja wersji docelowej ma znaczenie, gdy aktywne są reguły pyupgrade. Nowoczesna składnia może być poprawna dla jednej bazowej wersji interpretera, a nieużywalna dla innej.

Zespoły powinny zweryfikować, czy skonfigurowany w Ruffie docelowy Python odpowiada rzeczywistości wdrożeniowej. W przeciwnym razie zalecenia modernizacyjne mogą wyprzedzić wsparcie produkcyjne.

Kod generowany również wymaga osobnego traktowania. Ponowne formatowanie lub lintowanie wygenerowanych plików często tworzy zmiany, które znikają przy kolejnym uruchomieniu generatora.

Wykluczenie ścieżek generowanych może być trafniejsze niż wypełnianie ich komentarzami wyciszającymi. Źródło lub szablon generatora jest zwykle właściwym miejscem do egzekwowania jakości.

Monorepozytoria napotykają kolejną komplikację. Różne pakiety mogą obsługiwać różne wersje Pythona albo utrzymywać odrębne polityki lintowania.

Ustawienie domyślne na poziomie katalogu głównego może uprościć operacje, ale może też narzucić jeden harmonogram migracji niepowiązanym komponentom. Konfiguracja per pakiet może lepiej odzwierciedlać odpowiedzialność za utrzymanie.

Główne sceptyczne pytanie brzmi, czy 413 reguł tworzy szeroko akceptowalną bazę. Astral udokumentował ten wybór, ale praktyczne wdrożenie zweryfikuje wskaźnik fałszywych alarmów i obciążenie związane ze zgodnością.

Awarie Willisona dostarczają jednego wczesnego sygnału, a nie reprezentatywnego badania. Pokazują, że zakłócenia są możliwe, nie że doświadczy ich większość użytkowników Ruffa.

Projekty korzystające już z jawnego select lub extend-select mogą zareagować inaczej. Ich efektywny zestaw reguł zależy od tego, jak ta konfiguracja współdziała z nową bazą.

Astral twierdzi, że zmiana nadal może ujawnić użyteczne reguły u skonfigurowanych użytkowników. Każdy zespół powinien sprawdzić rozstrzygnięty wybór, zamiast zakładać, że konfiguracja czyni wydanie nieistotnym.

Istnieje też ryzyko nadmiernej korekty. Przypięcie Ruffa przy pozostawieniu wszystkich innych narzędzi deweloperskich jako zmiennych rozwiązuje tylko jeden widoczny przypadek szerszego problemu.

Zespoły powinny zinwentaryzować formatery, programy do sprawdzania typów, narzędzia testowe, hooki pre-commit i generatory dokumentacji. Każde z nich może zmienić poprawne budowanie w awarię.

Trwała polityka jest prosta: wersjonuj środowisko, które decyduje, czy kod może zostać wydany. Obejmuje ona narzędzia, które programiści tradycyjnie uznają za opcjonalne.

Na co Simon Willison i użytkownicy Ruffa powinni zwrócić uwagę dalej

Kolejne trzy sygnały pokażą, czy szersza baza Ruffa stanie się akceptowaną polityką, czy powracającym źródłem tarć w CI.

Pierwszym sygnałem będzie aktywność Astral związana z wydaniami poprawkowymi w tygodniach po wersji 0.16.0. Szybkie korekty domyślnych reguł wskazywałyby, że rzeczywiste repozytoria ujawniły istotne problemy ze zgodnością.

Korekty dotyczące konkretnych reguł nie podważałyby rozszerzonej bazy. Pokazałyby, że znacznie większy zestaw wymaga dostrojenia pod obciążeniem produkcyjnym.

Z kolei ograniczona aktywność związana z wycofywaniem zmian wzmocniłaby argument Astral, że większość nowych diagnostyk nadaje się do działania. Zachęciłaby też więcej projektów do zaakceptowania ustawień domyślnych zamiast przywracania wcześniejszego zestawu.

Drugim sygnałem będzie zachowanie konfiguracji w publicznych repozytoriach Pythona. Opiekunowie ujawnią swoją ocenę poprzez commity, nawet bez formalnych ankiet.

Fala jawnych wyborów starych ustawień domyślnych sugerowałaby, że zespoły bardziej cenią kontrolę migracji niż natychmiastowy zakres kontroli. Powszechne poprawki i zachowanie ustawień domyślnych wskazywałyby na udane wdrożenie.

Najbardziej wartościowe informacyjnie repozytoria udokumentują swoje uzasadnienie. Sama lista ignorowanych reguł pokazuje, co się zmieniło, podczas gdy notatka o migracji wyjaśnia, dlaczego zespół przyjął lub odrzucił każdą rodzinę reguł.

Trzecim sygnałem będzie to, czy szablony pakietów i przykłady CI zaczną przypinać Ruffa. Generatory nowych projektów często kształtują nawyki skuteczniej niż ostrzeżenia formułowane z perspektywy czasu.

Jeśli szablony przyjmą ograniczenia wersji i zautomatyzowane przepływy aktualizacji, doświadczenie Willisona wpłynie na praktykę wykraczającą poza to pojedyncze wydanie.

Jeśli przykłady nadal będą instalować nieograniczone ruff, przyszłe zmiany ustawień domyślnych lub formatera mogą powtórzyć to samo zaskoczenie. Konkretna liczba reguł będzie inna, ale problem odtwarzalności pozostanie.

Programiści nie muszą czekać na te sygnały, zanim zaczną działać. Mogą uruchomić nową wersję na gałęzi, zachować wynik i zdecydować, które zgłoszenia poprawiają ich kod.

Przydatna komenda testowa to:

Określenie wersji sprawia, że eksperyment jest powtarzalny. Osobne uruchomienie ruff format --check . pomaga odróżnić błędy lintowania od zmian w Markdown lub formatowaniu kodu źródłowego.

Nie zaczynaj od dodawania globalnych ignorowań. Najpierw ustal, które reguły wykryły jednoznaczne błędy, które sugerują modernizację, a które wyrażają dyskusyjną politykę.

Następnie zapisz decyzję w konfiguracji i kontroli wersji. Zielona odznaka CI ma mniejszą wartość, gdy nikt nie wie, jaka umowa jakościowa ją zapewniła.

Ruff v0.16.0 pokazuje zaletę i koszt aktywnych ustawień domyślnych. Narzędzie wykrywa więcej bez konfiguracji, ale brak konfiguracji nie oznacza już niezmiennego zachowania.

Doświadczenie Simona Willisona przekuwa ten abstrakcyjny kompromis w bezpośrednie pytanie inżynierskie: czy Twoje repozytorium deklaruje narzędzia i polityki kontrolujące jego wydania?

Uruchom przypiętą wersję na gałęzi, sprawdź każdą nową rodzinę reguł i jawnie określ bazę. Kolejne poprawne budowanie powinno odzwierciedlać przeanalizowaną decyzję, a nie datę, w której CI akurat zainstalowało Ruffa.