Ruff v0.16.0 リリースノート / 新機能

Ruff v0.16.0 リリースノート / 新機能

Ruff v0.16.0 でデフォルトのリンティングが413ルールに拡大

Ruff v0.16.0 では、デフォルトで有効なルールの数が59から413に増加しました。この変更により、ユーザーは手動での設定なしに、構文エラーや即座に発生する実行時エラーを含む重大な問題を検出できるようになります。拡大されたルールセットには、flake8-bugbear (B)、pyupgrade (UP)、および Ruff 独自の RUF カテゴリのルールが含まれています。

以前のデフォルトルールセットを好むユーザーは、以下の設定を使用して元に戻すことができます。

[lint]
select = ["E4", "E7", "E9", "F"]

Markdown コードブロックのフォーマット

Ruff v0.16.0 では、Markdown ファイル内に埋め込まれた Python コードブロックをフォーマットできるようになりました。フォーマッタは、python、py、python3、py3、pyi、または pycon といった情報文字列を持つフェンス付きコードブロックを対象とします。

  • pyi ブロック: スタブファイルとしてフォーマットされます。
  • pycon ブロック: REPL セッションとしてフォーマットされます。
  • 標準的な Python ブロック: 通常の Python ファイルのフォーマットを使用してフォーマットされます。

この機能は Quarto ノートブック（例: ````{python}）にも拡張されています。フォーマットの抑制は、コードブロック内の fmt: offおよびfmt: on コメントを使用するか、ドキュメントの領域を囲むために HTML コメント（）を使用することで可能です。Markdown ファイル全体は extend-exclude` 設定によって除外できます。

ruff: ignore による抑制機能の強化

バージョン 0.16.0 では、新しい抑制コメント形式が導入されました。これは単独の行で使用でき、従来の ruff: disable および ruff: enable による範囲指定メカニズムよりも柔軟性が向上しています。

  • ruff: ignore: 同じ行、または次の論理行の診断を抑制します。これは、複数行にわたる関数ヘッダーに特に有用です。
  • ruff: file-ignore: ファイル全体に対して特定の診断を抑制し、ruff: noqa と同様に機能します。

両方のコメントタイプは、抑制の理由を説明するためのオプションの「reason」文字列をサポートしています。さらに、新しい --add-ignore CLI フラグにより、これらのコメントを自動的に追加できるようになりました。プレビューモードでは、これらのコメントはルールコードだけでなく、ルール名（例: unused-import）をサポートしています。

CLI 出力への統合された修正 diff

リンターおよびフォーマッタの修正内容が、check および format --check サブコマンドのデフォルトの full 出力形式内で、直接 diff として表示されるようになりました。以前は、これらの変更は --diff フラグを使用した場合にのみ表示され、その際、付随する説明的な診断は抑制されていました。

format --check は、機械読み取り可能な JSON や、GitHub および GitLab CI のアノテーションと互換性のある形式を含む、リンターで利用可能なすべての出力形式をサポートするようになりました。

JSON 出力に関する注意: filename、location、end_location、および fix.edits の位置フィールドが、空の文字列やデフォルトの座標（行 1、列 1）の代わりに null になる可能性があるという破壊的変更が導入されました。

安定化したルールと動作

安定化したルール

以下のルールを含むいくつかのルールが、プレビューから安定（stable）ステータスに移行しました：

  • AIR303 (airflow3-incompatible-function-signature)
  • CPY001 (missing-copyright-notice)
  • FURB164 (unnecessary-from-float)
  • FURB192 (sorted-min-max)
  • ISC004 (implicit-string-concatenation-in-collection-literal)
  • LOG004 (log-exception-outside-except-handler)
  • PLE0304 (invalid-bool-return-type)
  • PLR0917 (too-many-positional-arguments)
  • PLR1708 (stop-iteration-return)
  • RUF036 (none-not-at-end-of-union)
  • RUF063 (access-annotations-from-class-dict)
  • RUF068 (duplicate-entry-in-dunder-all)

安定化した動作

  • BLE001 (blind-except): critical、error、exception 以外のメソッドを介して例外がログに記録される場合、現在は抑制されます。
  • FA102 (future-required-type-annotation): collections.abc を含む、追加の PEP 585 互換 API をチェックするようになりました。
  • INT001, INT002, INT003: builtins._ への代入など、より一般的な gettext モジュールの使用パターンをチェックするようになりました。
  • S310 (suspicious-url-open-usage): 誤検知を減らすために、ローカルの文字列リテラル結合を解決するようになりました。
  • S508 および S509: 新しい PySNMP バージョンの推奨 API をサポートするようになりました。
  • UP019 (typing-text-str-alias): typing_extensions.Text を認識するようになりました。

コミュニティの視点

このリリースに関するコミュニティのフィードバックは、自動化の向上を評価する層と、厳格なリンティングを恣意的だと感じる層との間で意見が分かれています。

アップデートにより、以前のバージョンでは見逃されていた問題を拡大されたルールセットがキャッチするなど、コードの品質が即座に向上したと報告するユーザーもいます。一方で、このようなツールの「文法ナチ（grammar nazi）」的な性質を懸念し、厳格なフォーマットは時に書き手の意図を不明瞭にすることがあると主張するユーザーもいます。

アップデートの運用面に関しては、バージョンを固定していない CI 環境で v0.16.0 にアップデートすると、新しいデフォルトルールの流入により、即座にジョブが失敗する可能性があることが一部の開発者から指摘されています。

「よく耳を澄ませば、最新の UV を一斉にプルして失敗している何千もの CI ジョブの音が聞こえてくる。」

さらに、ツールをアップデートした際に自動的に新しいデフォルトルールセットを継承するのではなく、チームが自分のペースで新しいデフォルトルールセットをオプトインできるように、(Nix のような) stateVersion を実装することを提案するユーザーもいました。

Sources