@@ -64,7 +64,7 @@ available
6464 --tox [options] <files|dirs> -- general entry point for testing
6565 and linting of the Sage library
6666 -e <envlist> -- run specific test environments; default:
67- doctest,coverage,startuptime,pycodestyle-minimal,relint,codespell,rst,ruff-minimal
67+ doctest,coverage,startuptime,pycodestyle-minimal,relint,codespell,rst
6868 doctest -- run the Sage doctester
6969 (same as "sage -t")
7070 coverage -- give information about doctest coverage of files
@@ -75,13 +75,11 @@ available
7575 relint -- check whether some forbidden patterns appear
7676 codespell -- check for misspelled words in source code
7777 rst -- validate Python docstrings markup as reStructuredText
78- ruff-minimal -- check against Sage's minimal style conventions
7978 coverage.py -- run the Sage doctester with Coverage.py
8079 coverage.py-html -- run the Sage doctester with Coverage.py, generate HTML report
8180 pyright -- run the static typing checker pyright
8281 pycodestyle -- check against the Python style conventions of PEP8
8382 cython-lint -- check Cython files for code style
84- ruff -- check against Python style conventions
8583 -p auto -- run test environments in parallel
8684 --help -- show tox help
8785
@@ -310,20 +308,33 @@ for Python code, written in Rust.
310308It comes with a large choice of possible checks, and has the capacity
311309to fix some of the warnings it emits.
312310
313- Sage defines two configurations for ruff. The command ``./sage -tox -e ruff-minimal `` uses
314- ruff in a minimal configuration. As of Sage 10.3, the entire Sage library conforms to this
315- configuration. When preparing a Sage PR, developers should verify that
316- ``./sage -tox -e ruff-minimal `` passes.
311+ Sage we have two configuration files for ruff. `pyproject.toml ` in the root of the
312+ repository defines all rules we wish to follow. `.github/workflows/ruff.toml ` takes
313+ the configuration in `pyproject.toml ` and disables all rules that we do not already
314+ follow throughout the repository. Our lint GitHub Action workflow requires
315+ ``ruff check --config .github/workflows/ruff.toml --preview `` to pass. To speed up the
316+ code review process, developers should verify that this passes locally before submitting a PR.
317+ To make sure you are running the same version of `ruff ` locally as GitHub Actions, use the command
318+ ``uv run --frozen --only-group lint -- ruff check --config .github/workflows/ruff.toml --preview ``.
319+
320+ Developers are encouraged to locally run ``ruff check [path to changed files] ``
321+ to run the stricter configuration defined in `pyproject.toml ` and fix any linter
322+ failures on their new code. This will help to avoid follow-up formatting PRs as
323+ Sage moves toward full PEP 8 compliance. Developers may also choose to fix existing
324+ linter failures on files that they modify, but use common sense when deciding whether
325+ or not to do so. A small bug fix PR should not include a large number of
326+ code-style changes as this makes it harder for reviewers to evaluate the important changes.
327+
328+ When working on PRs to improve our alignment with our linter rules, the ``--statistics ``
329+ option can be passed to ``ruff `` to print out a list of all rules that are enabled in
330+ `pyproject.toml ` but are not currently followed throughout the repository and how many
331+ times each rule is violated. This is useful for finding low-hanging fruit for formatting PRs.
332+ Developers can also use ``--select [RULE CODES] `` to override the list of rules enabled in
333+ `pyproject.toml ` when testing additional rules to add to `pyproject.toml `, or
334+ ``--select-extend [RULE CODES] `` to add new rules to the existing confirmation.
335+ See the `Ruff documentation <https://docs.astral.sh/ruff/ >`_ to see all features and rules
336+ available.
317337
318- The second configuration is used with the command ``./sage -tox -e ruff `` and runs a
319- more thorough check. When preparing a PR that adds new code,
320- developers should verify that ``./sage -tox -e ruff `` does not
321- issue warnings for the added code. This will avoid later cleanup
322- PRs as the Sage codebase is moving toward full PEP 8 compliance.
323-
324- On the other hand, it is usually not advisable to mix coding-style
325- fixes with productive changes on the same PR because this would
326- makes it harder for reviewers to evaluate the changes.
327338
328339.. _section-tools-relint :
329340
0 commit comments