diff --git a/.markdownlint.yaml b/.markdownlint.yaml index 66c4aeca0e..1ae5cc4955 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -1,6 +1,10 @@ # default to true for all rules default: true +# MD007/unordered-list-indent +MD007: + indent: 4 + # MD033/no-inline-html MD033: false @@ -8,7 +12,4 @@ MD033: false MD041: false # MD013/line-length -MD013: - line_length: 100 - code_blocks: false - ignore_code_blocks: true +MD013: false diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 5209b8b84b..fe81f561de 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -22,6 +22,7 @@ repos: hooks: - id: mdformat additional_dependencies: + - mdformat-mkdocs - mdformat-black - black==23.1.0 # Must be the latest version of Black diff --git a/BREAKING_CHANGES.md b/BREAKING_CHANGES.md index cc69ea3483..f8c7b7913b 100644 --- a/BREAKING_CHANGES.md +++ b/BREAKING_CHANGES.md @@ -48,12 +48,12 @@ Taking `UP006` (rewrite `List[int]` to `list[int]`) as an example, the setting n follows: - On Python 3.7 and Python 3.8, setting `keep-runtime-typing = true` will cause Ruff to ignore - `UP006` violations, even if `from __future__ import annotations` is present in the file. - While such annotations are valid in Python 3.7 and Python 3.8 when combined with - `from __future__ import annotations`, they aren't supported by libraries like Pydantic and - FastAPI, which rely on runtime type checking. + `UP006` violations, even if `from __future__ import annotations` is present in the file. + While such annotations are valid in Python 3.7 and Python 3.8 when combined with + `from __future__ import annotations`, they aren't supported by libraries like Pydantic and + FastAPI, which rely on runtime type checking. - On Python 3.9 and above, the setting has no effect, as `list[int]` is a valid type annotation, - and libraries like Pydantic and FastAPI support it without issue. + and libraries like Pydantic and FastAPI support it without issue. In short: `keep-runtime-typing` can be used to ensure that Ruff doesn't introduce type annotations that are not supported at runtime by the current Python version, which are unsupported by libraries @@ -203,25 +203,25 @@ This change is largely backwards compatible -- most users should experience no change in behavior. However, please note the following exceptions: - Subcommands will now fail when invoked with unsupported arguments, instead - of silently ignoring them. For example, the following will now fail: + of silently ignoring them. For example, the following will now fail: - ```console - ruff --clean --respect-gitignore - ``` + ```console + ruff --clean --respect-gitignore + ``` - (the `clean` command doesn't support `--respect-gitignore`.) + (the `clean` command doesn't support `--respect-gitignore`.) - The semantics of `ruff ` have changed slightly when `` is a valid subcommand. - For example, prior to this release, running `ruff rule` would run `ruff` over a file or - directory called `rule`. Now, `ruff rule` would invoke the `rule` subcommand. This should - only impact projects with files or directories named `rule`, `check`, `explain`, `clean`, - or `generate-shell-completion`. + For example, prior to this release, running `ruff rule` would run `ruff` over a file or + directory called `rule`. Now, `ruff rule` would invoke the `rule` subcommand. This should + only impact projects with files or directories named `rule`, `check`, `explain`, `clean`, + or `generate-shell-completion`. - Scripts that invoke ruff should supply `--` before any positional arguments. - (The semantics of `ruff -- ` have not changed.) + (The semantics of `ruff -- ` have not changed.) - `--explain` previously treated `--format grouped` as a synonym for `--format text`. - This is no longer supported; instead, use `--format text`. + This is no longer supported; instead, use `--format text`. ## 0.0.226 diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index a2c1808f2e..082e32b553 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -6,10 +6,10 @@ - [Scope](#scope) - [Enforcement](#enforcement) - [Enforcement Guidelines](#enforcement-guidelines) - - [1. Correction](#1-correction) - - [2. Warning](#2-warning) - - [3. Temporary Ban](#3-temporary-ban) - - [4. Permanent Ban](#4-permanent-ban) + - [1. Correction](#1-correction) + - [2. Warning](#2-warning) + - [3. Temporary Ban](#3-temporary-ban) + - [4. Permanent Ban](#4-permanent-ban) - [Attribution](#attribution) ## Our Pledge @@ -33,20 +33,20 @@ community include: - Being respectful of differing opinions, viewpoints, and experiences - Giving and gracefully accepting constructive feedback - Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience + and learning from the experience - Focusing on what is best not just for us as individuals, but for the - overall community + overall community Examples of unacceptable behavior include: - The use of sexualized language or imagery, and sexual attention or - advances of any kind + advances of any kind - Trolling, insulting or derogatory comments, and personal or political attacks - Public or private harassment - Publishing others' private information, such as a physical or email - address, without their explicit permission + address, without their explicit permission - Other conduct which could reasonably be considered inappropriate in a - professional setting + professional setting ## Enforcement Responsibilities diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6864a7ecd1..55ac25f836 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,13 +3,13 @@ Welcome! We're happy to have you here. Thank you in advance for your contribution to Ruff. - [The Basics](#the-basics) - - [Prerequisites](#prerequisites) - - [Development](#development) - - [Project Structure](#project-structure) - - [Example: Adding a new lint rule](#example-adding-a-new-lint-rule) - - [Rule naming convention](#rule-naming-convention) - - [Rule testing: fixtures and snapshots](#rule-testing-fixtures-and-snapshots) - - [Example: Adding a new configuration option](#example-adding-a-new-configuration-option) + - [Prerequisites](#prerequisites) + - [Development](#development) + - [Project Structure](#project-structure) + - [Example: Adding a new lint rule](#example-adding-a-new-lint-rule) + - [Rule naming convention](#rule-naming-convention) + - [Rule testing: fixtures and snapshots](#rule-testing-fixtures-and-snapshots) + - [Example: Adding a new configuration option](#example-adding-a-new-configuration-option) - [MkDocs](#mkdocs) - [Release Process](#release-process) - [Benchmarks](#benchmarking-and-profiling) @@ -23,9 +23,10 @@ For small changes (e.g., bug fixes), feel free to submit a PR. For larger changes (e.g., new lint rules, new functionality, new configuration options), consider creating an [**issue**](https://github.com/astral-sh/ruff/issues) outlining your proposed change. You can also join us on [**Discord**](https://discord.gg/c9MhzV8aU5) to discuss your idea with the -community. We have labeled [beginner-friendly tasks in the issue tracker](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) -as well as [bugs](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Abug) and -[improvements that are ready for contributions](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted). +community. We've labeled [beginner-friendly tasks](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) +in the issue tracker, along with [bugs](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Abug) +and [improvements](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted) +that are ready for contributions. If you're looking for a place to start, we recommend implementing a new lint rule (see: [_Adding a new lint rule_](#example-adding-a-new-lint-rule), which will allow you to learn from and @@ -100,19 +101,19 @@ At time of writing, the repository includes the following crates: - `crates/ruff_cache`: library crate for caching lint results. - `crates/ruff_cli`: binary crate containing Ruff's command-line interface. - `crates/ruff_dev`: binary crate containing utilities used in the development of Ruff itself (e.g., - `cargo dev generate-all`). + `cargo dev generate-all`). - `crates/ruff_diagnostics`: library crate for the lint diagnostics APIs. - `crates/ruff_formatter`: library crate for generic code formatting logic based on an intermediate - representation. + representation. - `crates/ruff_index`: library crate inspired by `rustc_index`. - `crates/ruff_macros`: library crate containing macros used by Ruff. - `crates/ruff_python_ast`: library crate containing Python-specific AST types and utilities. - `crates/ruff_python_formatter`: library crate containing Python-specific code formatting logic. - `crates/ruff_python_semantic`: library crate containing Python-specific semantic analysis logic, - including Ruff's semantic model. + including Ruff's semantic model. - `crates/ruff_python_stdlib`: library crate containing Python-specific standard library data. - `crates/ruff_python_whitespace`: library crate containing Python-specific whitespace analysis - logic. + logic. - `crates/ruff_rustpython`: library crate containing `RustPython`-specific utilities. - `crates/ruff_testing_macros`: library crate containing macros used for testing Ruff. - `crates/ruff_textwrap`: library crate to indent and dedent Python source code. @@ -123,21 +124,21 @@ At time of writing, the repository includes the following crates: At a high level, the steps involved in adding a new lint rule are as follows: 1. Determine a name for the new rule as per our [rule naming convention](#rule-naming-convention) - (e.g., `AssertFalse`, as in, "allow `assert False`"). + (e.g., `AssertFalse`, as in, "allow `assert False`"). 1. Create a file for your rule (e.g., `crates/ruff/src/rules/flake8_bugbear/rules/assert_false.rs`). 1. In that file, define a violation struct (e.g., `pub struct AssertFalse`). You can grep for - `#[violation]` to see examples. + `#[violation]` to see examples. 1. In that file, define a function that adds the violation to the diagnostic list as appropriate - (e.g., `pub(crate) fn assert_false`) based on whatever inputs are required for the rule (e.g., - an `ast::StmtAssert` node). + (e.g., `pub(crate) fn assert_false`) based on whatever inputs are required for the rule (e.g., + an `ast::StmtAssert` node). 1. Define the logic for triggering the violation in `crates/ruff/src/checkers/ast/mod.rs` (for - AST-based checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks), - `crates/ruff/src/checkers/lines.rs` (for text-based checks), or - `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based checks). + AST-based checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks), + `crates/ruff/src/checkers/lines.rs` (for text-based checks), or + `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based checks). 1. Map the violation struct to a rule code in `crates/ruff/src/codes.rs` (e.g., `B011`). @@ -170,13 +171,13 @@ suppression comment would be framed as "allow `assert False`". As such, rule names should... - Highlight the pattern that is being linted against, rather than the preferred alternative. - For example, `AssertFalse` guards against `assert False` statements. + For example, `AssertFalse` guards against `assert False` statements. - _Not_ contain instructions on how to fix the violation, which instead belong in the rule - documentation and the `autofix_title`. + documentation and the `autofix_title`. - _Not_ contain a redundant prefix, like `Disallow` or `Banned`, which are already implied by the - convention. + convention. When re-implementing rules from other linters, we prioritize adhering to this convention over preserving the original rule name. @@ -191,25 +192,25 @@ Ruff's output for each fixture, which you can then commit alongside your changes Once you've completed the code for the rule itself, you can define tests with the following steps: 1. Add a Python file to `crates/ruff/resources/test/fixtures/[linter]` that contains the code you - want to test. The file name should match the rule name (e.g., `E402.py`), and it should include - examples of both violations and non-violations. + want to test. The file name should match the rule name (e.g., `E402.py`), and it should include + examples of both violations and non-violations. 1. Run Ruff locally against your file and verify the output is as expected. Once you're satisfied - with the output (you see the violations you expect, and no others), proceed to the next step. - For example, if you're adding a new rule named `E402`, you would run: + with the output (you see the violations you expect, and no others), proceed to the next step. + For example, if you're adding a new rule named `E402`, you would run: - ```shell - cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache - ``` + ```shell + cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache + ``` 1. Add the test to the relevant `crates/ruff/src/rules/[linter]/mod.rs` file. If you're contributing - a rule to a pre-existing set, you should be able to find a similar example to pattern-match - against. If you're adding a new linter, you'll need to create a new `mod.rs` file (see, - e.g., `crates/ruff/src/rules/flake8_bugbear/mod.rs`) + a rule to a pre-existing set, you should be able to find a similar example to pattern-match + against. If you're adding a new linter, you'll need to create a new `mod.rs` file (see, + e.g., `crates/ruff/src/rules/flake8_bugbear/mod.rs`) 1. Run `cargo test`. Your test will fail, but you'll be prompted to follow-up - with `cargo insta review`. Run `cargo insta review`, review and accept the generated snapshot, - then commit the snapshot file alongside the rest of your changes. + with `cargo insta review`. Run `cargo insta review`, review and accept the generated snapshot, + then commit the snapshot file alongside the rest of your changes. 1. Run `cargo test` again to ensure that your test passes. @@ -247,25 +248,25 @@ To preview any changes to the documentation locally: 1. Install MkDocs and Material for MkDocs with: - ```shell - pip install -r docs/requirements.txt - ``` + ```shell + pip install -r docs/requirements.txt + ``` 1. Generate the MkDocs site with: - ```shell - python scripts/generate_mkdocs.py - ``` + ```shell + python scripts/generate_mkdocs.py + ``` 1. Run the development server with: - ```shell - # For contributors. - mkdocs serve -f mkdocs.generated.yml + ```shell + # For contributors. + mkdocs serve -f mkdocs.generated.yml - # For members of the Astral org, which has access to MkDocs Insiders via sponsorship. - mkdocs serve -f mkdocs.insiders.yml - ``` + # For members of the Astral org, which has access to MkDocs Insiders via sponsorship. + mkdocs serve -f mkdocs.insiders.yml + ``` The documentation should then be available locally at [http://127.0.0.1:8000/docs/](http://127.0.0.1:8000/docs/). @@ -286,20 +287,19 @@ even patch releases may contain [non-backwards-compatible changes](https://semve 1. Create a PR with the version and `BREAKING_CHANGES.md` updated 1. Merge the PR 1. Run the release workflow with the version number (without starting `v`) as input. Make sure - main has your merged PR as last commit + main has your merged PR as last commit 1. The release workflow will do the following: - 1. Build all the assets. If this fails (even though we tested in step 4), we haven’t tagged or - uploaded anything, you can restart after pushing a fix - 1. Upload to pypi - 1. Create and push the git tag (from pyproject.toml). We create the git tag only here - because we can't change it ([#4468](https://github.com/charliermarsh/ruff/issues/4468)), so - we want to make sure everything up to and including publishing to pypi worked. - 1. Attach artifacts to draft GitHub release - 1. Trigger downstream repositories. This can fail without causing fallout, it is possible (if - inconvenient) to trigger the downstream jobs manually -1. Create release notes in GitHub UI and promote from draft to proper release() + 1. Build all the assets. If this fails (even though we tested in step 4), we haven’t tagged or + uploaded anything, you can restart after pushing a fix. + 1. Upload to PyPI. + 1. Create and push the Git tag (as extracted from `pyproject.toml`). We create the Git tag only + after building the wheels and uploading to PyPI, since we can't delete or modify the tag ([#4468](https://github.com/charliermarsh/ruff/issues/4468)). + 1. Attach artifacts to draft GitHub release + 1. Trigger downstream repositories. This can fail non-catastrophically, as we can run any + downstream jobs manually if needed. +1. Create release notes in GitHub UI and promote from draft. 1. If needed, [update the schemastore](https://github.com/charliermarsh/ruff/blob/main/scripts/update_schemastore.py) -1. If needed, update ruff-lsp and ruff-vscode +1. If needed, update the `ruff-lsp` and `ruff-vscode` repositories. ## Ecosystem CI @@ -452,7 +452,7 @@ You can run the benchmarks with cargo benchmark ``` -#### Benchmark driven Development +#### Benchmark-driven Development Ruff uses [Criterion.rs](https://bheisler.github.io/criterion.rs/book/) for benchmarks. You can use `--save-baseline=` to store an initial baseline benchmark (e.g. on `main`) and then use @@ -491,7 +491,7 @@ cargo install critcmp #### Tips - Use `cargo benchmark ` to only run specific benchmarks. For example: `cargo benchmark linter/pydantic` - to only run the pydantic tests. + to only run the pydantic tests. - Use `cargo benchmark --quiet` for a more cleaned up output (without statistical relevance) - Use `cargo benchmark --quick` to get faster results (more prone to noise) @@ -550,7 +550,7 @@ cargo instruments -t time --bench linter --profile release-debug -p ruff_benchma ``` - `-t`: Specifies what to profile. Useful options are `time` to profile the wall time and `alloc` - for profiling the allocations. + for profiling the allocations. - You may want to pass an additional filter to run a single test file Otherwise, follow the instructions from the linux section. @@ -561,12 +561,12 @@ Otherwise, follow the instructions from the linux section. utils with it: - `cargo dev print-ast `: Print the AST of a python file using the - [RustPython parser](https://github.com/astral-sh/RustPython-Parser/tree/main/parser) that is - mainly used in Ruff. For `if True: pass # comment`, you can see the syntax tree, the byte offsets - for start and stop of each node and also how the `:` token, the comment and whitespace are not - represented anymore: + [RustPython parser](https://github.com/astral-sh/RustPython-Parser/tree/main/parser) that is + mainly used in Ruff. For `if True: pass # comment`, you can see the syntax tree, the byte offsets + for start and stop of each node and also how the `:` token, the comment and whitespace are not + represented anymore: -```text +````text [ If( StmtIf { @@ -591,7 +591,7 @@ utils with it: }, ), ] -``` + ``` - `cargo dev print-tokens `: Print the tokens that the AST is built upon. Again for `if True: pass # comment`: @@ -605,11 +605,11 @@ utils with it: "# comment", ) 23 23 Newline 24 -``` +```` - `cargo dev print-cst `: Print the CST of a python file using - [LibCST](https://github.com/Instagram/LibCST), which is used in addition to the RustPython parser - in Ruff. E.g. for `if True: pass # comment` everything including the whitespace is represented: + [LibCST](https://github.com/Instagram/LibCST), which is used in addition to the RustPython parser + in Ruff. E.g. for `if True: pass # comment` everything including the whitespace is represented: ```text Module { @@ -675,13 +675,13 @@ Module { ``` - `cargo dev generate-all`: Update `ruff.schema.json`, `docs/configuration.md` and `docs/rules`. - You can also set `RUFF_UPDATE_SCHEMA=1` to update `ruff.schema.json` during `cargo test`. + You can also set `RUFF_UPDATE_SCHEMA=1` to update `ruff.schema.json` during `cargo test`. - `cargo dev generate-cli-help`, `cargo dev generate-docs` and `cargo dev generate-json-schema`: - Update just `docs/configuration.md`, `docs/rules` and `ruff.schema.json` respectively. + Update just `docs/configuration.md`, `docs/rules` and `ruff.schema.json` respectively. - `cargo dev generate-options`: Generate a markdown-compatible table of all `pyproject.toml` - options. Used for + options. Used for - `cargo dev generate-rules-table`: Generate a markdown-compatible table of all rules. Used for - `cargo dev round-trip `: Read a Python file or Jupyter Notebook, - parse it, serialize the parsed representation and write it back. Used to check how good our - representation is so that fixes don't rewrite irrelevant parts of a file. + parse it, serialize the parsed representation and write it back. Used to check how good our + representation is so that fixes don't rewrite irrelevant parts of a file. - `cargo dev format_dev`: See ruff_python_formatter README.md diff --git a/README.md b/README.md index 7b1087920d..8ad8cf8fd3 100644 --- a/README.md +++ b/README.md @@ -32,10 +32,10 @@ An extremely fast Python linter, written in Rust. - 🔧 Autofix support, for automatic error correction (e.g., automatically remove unused imports) - 📏 Over [500 built-in rules](https://beta.ruff.rs/docs/rules/) - ⚖️ [Near-parity](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) with the - built-in Flake8 rule set + built-in Flake8 rule set - 🔌 Native re-implementations of dozens of Flake8 plugins, like flake8-bugbear - ⌨️ First-party [editor integrations](https://beta.ruff.rs/docs/editor-integrations/) for - [VS Code](https://github.com/astral-sh/ruff-vscode) and [more](https://github.com/astral-sh/ruff-lsp) + [VS Code](https://github.com/astral-sh/ruff-vscode) and [more](https://github.com/astral-sh/ruff-lsp) - 🌎 Monorepo-friendly, with [hierarchical and cascading configuration](https://beta.ruff.rs/docs/configuration/#pyprojecttoml-discovery) Ruff aims to be orders of magnitude faster than alternative tools while integrating more @@ -364,8 +364,8 @@ Ruff is used by a number of major open-source projects and companies, including: - [Great Expectations](https://github.com/great-expectations/great_expectations) - [HTTPX](https://github.com/encode/httpx) - Hugging Face ([Transformers](https://github.com/huggingface/transformers), - [Datasets](https://github.com/huggingface/datasets), - [Diffusers](https://github.com/huggingface/diffusers)) + [Datasets](https://github.com/huggingface/datasets), + [Diffusers](https://github.com/huggingface/diffusers)) - [Hatch](https://github.com/pypa/hatch) - [Home Assistant](https://github.com/home-assistant/core) - ING Bank ([popmon](https://github.com/ing-bank/popmon), [probatus](https://github.com/ing-bank/probatus)) @@ -377,8 +377,8 @@ Ruff is used by a number of major open-source projects and companies, including: - [MegaLinter](https://github.com/oxsecurity/megalinter) - Meltano ([Meltano CLI](https://github.com/meltano/meltano), [Singer SDK](https://github.com/meltano/sdk)) - Microsoft ([Semantic Kernel](https://github.com/microsoft/semantic-kernel), - [ONNX Runtime](https://github.com/microsoft/onnxruntime), - [LightGBM](https://github.com/microsoft/LightGBM)) + [ONNX Runtime](https://github.com/microsoft/onnxruntime), + [LightGBM](https://github.com/microsoft/LightGBM)) - Modern Treasury ([Python SDK](https://github.com/Modern-Treasury/modern-treasury-python-sdk)) - Mozilla ([Firefox](https://github.com/mozilla/gecko-dev)) - [Mypy](https://github.com/python/mypy) diff --git a/crates/flake8_to_ruff/README.md b/crates/flake8_to_ruff/README.md index e0a073b5ee..b8a453d7c8 100644 --- a/crates/flake8_to_ruff/README.md +++ b/crates/flake8_to_ruff/README.md @@ -82,12 +82,12 @@ flake8-to-ruff path/to/.flake8 --plugin flake8-builtins --plugin flake8-quotes ## Limitations 1. Ruff only supports a subset of the Flake configuration options. `flake8-to-ruff` will warn on and - ignore unsupported options in the `.flake8` file (or equivalent). (Similarly, Ruff has a few - configuration options that don't exist in Flake8.) + ignore unsupported options in the `.flake8` file (or equivalent). (Similarly, Ruff has a few + configuration options that don't exist in Flake8.) 1. Ruff will omit any rule codes that are unimplemented or unsupported by Ruff, including rule - codes from unsupported plugins. (See the - [documentation](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) for the complete - list of supported plugins.) + codes from unsupported plugins. (See the + [documentation](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) for the complete + list of supported plugins.) ## License diff --git a/crates/ruff_python_formatter/README.md b/crates/ruff_python_formatter/README.md index f4d63100e4..2484326805 100644 --- a/crates/ruff_python_formatter/README.md +++ b/crates/ruff_python_formatter/README.md @@ -282,7 +282,7 @@ Compared to `ruff check`, `cargo run --bin ruff_dev -- format-dev` has 4 additio - `--stability-check`: Format twice (but don't write to disk) and check for differences and crashes - `--multi-project`: Treat every subdirectory as a separate project. Useful for ecosystem checks. - `--error-file`: Use together with `--multi-project`, this writes all errors (but not status - messages) to a file. + messages) to a file. ## The orphan rules and trait structure diff --git a/docs/configuration.md b/docs/configuration.md index 3575253ed7..25b151cf5f 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -106,13 +106,13 @@ formats. Ruff will automatically disable any conflicting rules when `ALL` is ena If you're wondering how to configure Ruff, here are some **recommended guidelines**: - Prefer `select` and `ignore` over `extend-select` and `extend-ignore`, to make your rule set - explicit. + explicit. - Use `ALL` with discretion. Enabling `ALL` will implicitly enable new rules whenever you upgrade. - Start with a small set of rules (`select = ["E", "F"]`) and add a category at-a-time. For example, - you might consider expanding to `select = ["E", "F", "B"]` to enable the popular flake8-bugbear - extension. + you might consider expanding to `select = ["E", "F", "B"]` to enable the popular flake8-bugbear + extension. - By default, Ruff's autofix is aggressive. If you find that it's too aggressive for your liking, - consider turning off autofix for specific rules or categories (see [_FAQ_](faq.md#ruff-tried-to-fix-something--but-it-broke-my-code)). + consider turning off autofix for specific rules or categories (see [_FAQ_](faq.md#ruff-tried-to-fix-something--but-it-broke-my-code)). ## Using `ruff.toml` @@ -284,17 +284,17 @@ directory hierarchy is used for every individual file, with all paths in the `py There are a few exceptions to these rules: 1. In locating the "closest" `pyproject.toml` file for a given path, Ruff ignores any - `pyproject.toml` files that lack a `[tool.ruff]` section. + `pyproject.toml` files that lack a `[tool.ruff]` section. 1. If a configuration file is passed directly via `--config`, those settings are used for across - files. Any relative paths in that configuration file (like `exclude` globs or `src` paths) are - resolved relative to the _current working directory_. + files. Any relative paths in that configuration file (like `exclude` globs or `src` paths) are + resolved relative to the _current working directory_. 1. If no `pyproject.toml` file is found in the filesystem hierarchy, Ruff will fall back to using - a default configuration. If a user-specific configuration file exists - at `${config_dir}/ruff/pyproject.toml`, that file will be used instead of the default - configuration, with `${config_dir}` being determined via the [`dirs`](https://docs.rs/dirs/4.0.0/dirs/fn.config_dir.html) - crate, and all relative paths being again resolved relative to the _current working directory_. + a default configuration. If a user-specific configuration file exists + at `${config_dir}/ruff/pyproject.toml`, that file will be used instead of the default + configuration, with `${config_dir}` being determined via the [`dirs`](https://docs.rs/dirs/4.0.0/dirs/fn.config_dir.html) + crate, and all relative paths being again resolved relative to the _current working directory_. 1. Any `pyproject.toml`-supported settings that are provided on the command-line (e.g., via - `--select`) will override the settings in _every_ resolved configuration file. + `--select`) will override the settings in _every_ resolved configuration file. Unlike [ESLint](https://eslint.org/docs/latest/user-guide/configuring/configuration-files#cascading-and-hierarchy), Ruff does not merge settings across configuration files; instead, the "closest" configuration file @@ -462,18 +462,18 @@ By default, Ruff exits with the following status codes: - `0` if no violations were found, or if all present violations were fixed automatically. - `1` if violations were found. - `2` if Ruff terminates abnormally due to invalid configuration, invalid CLI options, or an - internal error. + internal error. This convention mirrors that of tools like ESLint, Prettier, and RuboCop. Ruff supports two command-line flags that alter its exit code behavior: - `--exit-zero` will cause Ruff to exit with a status code of `0` even if violations were found. - Note that Ruff will still exit with a status code of `2` if it terminates abnormally. + Note that Ruff will still exit with a status code of `2` if it terminates abnormally. - `--exit-non-zero-on-fix` will cause Ruff to exit with a status code of `1` if violations were - found, _even if_ all such violations were fixed automatically. Note that the use of - `--exit-non-zero-on-fix` can result in a non-zero exit code even if no violations remain after - autofixing. + found, _even if_ all such violations were fixed automatically. Note that the use of + `--exit-non-zero-on-fix` can result in a non-zero exit code even if no violations remain after + autofixing. ## Autocompletion diff --git a/docs/faq.md b/docs/faq.md index 3ce02b7f98..7e74076c05 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -94,8 +94,8 @@ There are a few other minor incompatibilities between Ruff and the originating F - Ruff doesn't implement all the "opinionated" lint rules from flake8-bugbear. - Depending on your project structure, Ruff and isort can differ in their detection of first-party - code. (This is often solved by modifying the `src` property, e.g., to `src = ["src"]`, if your - code is nested in a `src` directory.) + code. (This is often solved by modifying the `src` property, e.g., to `src = ["src"]`, if your + code is nested in a `src` directory.) ## How does Ruff compare to Pylint? diff --git a/playground/README.md b/playground/README.md index befd81a0af..7b13420928 100644 --- a/playground/README.md +++ b/playground/README.md @@ -5,7 +5,7 @@ In-browser playground for Ruff. Available [https://play.ruff.rs/](https://play.r ## Getting started - To build the WASM module, run `wasm-pack build ../crates/ruff_wasm --target web --out-dir ../../playground/src/pkg` - from the `./playground` directory. + from the `./playground` directory. - Install TypeScript dependencies with: `npm install`. - Start the development server with: `npm run dev`.