Release 1.0.0

CHANGELOG.md

@@ -19,6 +19,69 @@ Semantic versioning in our case means:
 
 ## 1.0.0 WIP
 
+### Ruff
+
+This release introduces the new main concept: `ruff` compatibility.
+
+Now `WPS` is the only `flake8` plugin that is installed.
+Other things are done by `ruff`.
+It is faster, it has autofixing, there are lots of rules.
+Basically, this way `WPS` just gain lots
+of new rule and plugins almost for free.
+It is now stricter than ever! `WPS` now officially supports
+**ALL** `ruff` existing rules. This means that there are no conflicts
+between two linters.
+
+To run `WPS` and `ruff` together, use:
+
+```bash
+ruff format && ruff check && flake8 --select=WSP .
+```
+
+You can copy our configuration from [`pyproject.toml`](https://github.com/wemake-services/wemake-python-styleguide/blob/bca0a1452335619ee5898e2ab657ca6e4a741f5f/pyproject.toml#L103) (for `ruff`) and [`setup.cfg`](https://github.com/wemake-services/wemake-python-styleguide/blob/bca0a1452335619ee5898e2ab657ca6e4a741f5f/setup.cfg#L7) (for `flake8`).
+
+### Black
+
+`WPS` can now also be used with `black` with **default** configuration.
+However, we recommend using `ruff format` instead.
+
+### Speed
+
+`WPS` got a lot faster! Because:
+- We removed a lot of `flake8` plugins
+- We removed a lot of rules covered by `ruff`
+
+Running `0.19.2` (previous version) on https://github.com/dry-python/returns
+
+```bash
+» time flake8 .
+flake8 .  20.63s user 2.47s system 469% cpu 4.919 total
+```
+
+The same on `1.0.0`:
+
+```
+» time flake8 .
+flake8 .  8.56s user 0.54s system 898% cpu 1.013 total
+```
+
+Which is **2.4x** times faster!
+
+### Integrations
+
+We also significantly improved all the integrations!
+`WPS` can now be used as first-class `pre-commit` hook with:
+
+```yaml
+repos:
+- repo: https://github.com/wemake-services/wemake-python-styleguide
+  rev: 1.0.0
+  hooks:
+    - id: wemake-python-styleguide
+```
+
+Our [GitHub Action](https://github.com/marketplace/actions/wemake-python-styleguide) also got a lot of new options and fixes.
+
 ### Removals
 
 - **Breaking**: Drops `python3.9` support
@@ -98,7 +161,7 @@ Semantic versioning in our case means:
   with code that you want to exclude, there's no need
   to create one more way of disabling some specific violations
 
-## Features
+### Features
 
 - Adds official `python3.13` support
 - Allows any compares in `assert` statements for `WPS520`, #3112

Dockerfile

@@ -20,7 +20,7 @@ FROM python:3.12.7-alpine
 LABEL maintainer="[email protected]"
 LABEL vendor="wemake.services"
 
-ENV WPS_VERSION='0.19.2'
+ENV WPS_VERSION='1.0.0'
 ENV REVIEWDOG_VERSION='v0.20.3'
 
 RUN apk add --no-cache bash git wget

README.md

@@ -19,8 +19,9 @@ Welcome to the strictest and most opinionated Python linter ever.
 </p>
 
 `wemake-python-styleguide` is actually a [flake8](http://flake8.pycqa.org/en/latest/)
-plugin with [some other plugins](https://wemake-python-styleguide.rtfd.io/en/latest/pages/usage/violations/index.html#external-plugins) as dependencies.
+plugin, the only one you will need as your [ruff](https://github.com/astral-sh/ruff) companion.
 
+Fully compatible with **ALL** rules and format conventions from `ruff`.
 
 ## Quickstart
 
@@ -40,7 +41,7 @@ We highly recommend to also use:
 ## Running
 
 ```bash
-flake8 your_module.py
+flake8 your_module.py --select=WPS
 ```
 
 This app is still just good old `flake8`!
@@ -57,6 +58,15 @@ in the docs for examples and integrations.
 We also support [GitHub Actions](https://wemake-python-styleguide.rtfd.io/en/latest/pages/usage/integrations/github-actions.html) as first class-citizens.
 [Try it out](https://github.com/marketplace/actions/wemake-python-styleguide)!
 
+Can (and should!) be used with `ruff`:
+
+```bash
+ruff check && ruff format
+flake8 . --select=WPS
+```
+
+See example `ruff` configuration in our [`pyproject.toml`](https://github.com/wemake-services/wemake-python-styleguide/blob/master/pyproject.toml#L103).
+
 
 ## Strict is the new cool
 
@@ -96,14 +106,14 @@ You can find all error codes and plugins [in the docs](https://wemake-python-sty
 We are *not* planning to do the following things:
 
 0. Assume or check types, use `mypy` together with our linter
-1. [Reformat code](https://wemake-python-styleguide.rtfd.io/en/latest/pages/usage/integrations/auto-formatters.html), since we believe that developers should do that
+1. Format code or produce stylistic errors, use `ruff format` for that
 2. Check for `SyntaxError` or logical bugs, write tests instead
 3. Appeal to everyone. But, you can [switch off](https://wemake-python-styleguide.rtfd.io/en/latest/pages/usage/setup.html#ignoring-violations) any rules that you don't like
 
 
 ## Supporting us :tada:
 
-We in [wemake.services](https://wemake.services) make
+We in [wemake.services](https://github.com/wemake-services) make
 all our tools open-source by default, so the community can benefit from them.
 If you use our tools and they make your life easier and brings business value,
 you can return us a favor by supporting the work we do.

docs/pages/usage/configuration.rst

@@ -15,53 +15,6 @@ the configuration to all ``python`` projects.
 .. automodule:: wemake_python_styleguide.options.config
    :no-members:
 
-.. rubric:: Plugins
-
-It is also important to configure different plugins that we ship with
-this module.
-
-All recommended settings can be found in our `styleguide.toml <https://github.com/wemake-services/wemake-python-styleguide/blob/master/styles/styleguide.toml>`_.
-
-You can basically configure them as you wish,
-including stylistic (like ``--quotes`` from ``flake8-quotes``)
-and important things (like ``--max-complexity`` from ``mccabe``).
-Our `flake8.toml <https://github.com/wemake-services/wemake-python-styleguide/blob/master/styles/flake8.toml>`_
-file is available with the core settings for ``flake8``.
-
-**flake8-isort**
-
-We use ``flake8-isort`` to check style of imports in our code.
-To avoid triggering these checks, you can either use `"wemake" isort profile <https://pycqa.github.io/isort/docs/configuration/profiles.html#wemake>`_
-or update your configuration with the following lines:
-
-.. code:: ini
-
-  # Inside `setup.cfg`:
-
-  [isort]
-  include_trailing_comma = true
-  use_parentheses = true
-  multi_line_output = 3
-
-Our `isort.toml <https://github.com/wemake-services/wemake-python-styleguide/blob/master/styles/isort.toml>`_
-file is available with the core settings for ``isort``.
-
-**darglint**
-
-We use ``darglint`` to ensure that docstrings match NumPy documentation style.
-To avoid triggering these checks, please ensure that your configuration contains
-following settings:
-
-.. code:: ini
-
-  # Inside `setup.cfg`
-
-  [darglint]
-  strictness = long
-
-Our `darglint.toml <https://github.com/wemake-services/wemake-python-styleguide/blob/master/styles/darglint.toml>`_
-file is available with the core settings for ``isort``.
-
 .. rubric:: Ignoring violations
 
 We know that people might not agree with 100% of our rules.

docs/pages/usage/integrations/auto-formatters.rst

@@ -1,78 +1,28 @@
 Auto-formatters
 ---------------
 
-Autoformatters are very simple tools to do just a one thing:
-reformat some basic stuff in your code like quotes, commas, and line length.
+List of supported tools.
 
-The difference between a linter and auto-formatter is huge:
 
-- auto-formatters pretties your code a little bit
-- linters force you to write beautiful and correct code
+ruff
+~~~~
 
-For example, auto-formatters won't tell you that your code is too complex.
-When your linter will (in case it is a good linter).
+Fully supported.
+You can run ``ruff check && ruff format`` and there
+should be no conflicts with ``WPS`` at all.
 
-Autoformatters are also useless
-when dealing with rewriting actually bad code.
-Like code with bad variable names, unreachable branches,
-statements that have no effect.
+But, ``wemake-python-styleguide`` can and will find additional
+problems that ``ruff`` missed.
 
-We in ``wemake.services`` believe that these kind of tools are not required,
-because a good linter will just not let your badly formatted code pass the CI,
-so there would be no junk to reformat!
-All code is perfectly formatted all the time.
-
-Rely on strict linters, not auto-formatters.
-
-However, if you still want to use some autoformatter
-together with ``wemake-python-styleguide``
-we have made some research to help you!
 
 isort
 ~~~~~
 
-``isort`` is a great tool to sort your imports.
-We already use it to validate that your imports are correct.
-We recommend to use ``isort`` and officially
-and support it in a way that all
-valid ``wemake-python-styleguide`` code is valid ``isort`` code.
-But, **not the other way around**.
-
-You might be required to refactor your code manually after ``isort``
-reformat to make ``wemake-python-styleguide`` happy.
-
-``isort`` can also `be invoked <https://github.com/timothycrosley/isort#using-isort>`_
-as a command line tool to fix all your import problems for you.
-
-We recommend to run ``isort``. They are also compatible.
+We support ``isort``, but we recommend to use ``ruff`` instead.
+See https://docs.astral.sh/ruff/rules/#isort-i
 
-There are also plugins for IDEs to run ``isort`` on safe:
-
-- https://github.com/timothycrosley/isort/wiki/isort-Plugins
-- https://code.visualstudio.com/docs/python/editing
-
-You can find the configuration we use in ``setup.cfg`` in this repository.
 
 black
 ~~~~~
 
-``wemake-python-styleguide`` is not compatible with ``black``.
-Let's go deeper and see why.
-
-``black`` itself is actually not compatible with ``PEP8`` and ``flake8``
-(`docs <https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=flake8>`_),
-that's why it is not compatible with ``wemake-python-styleguide`` either.
-Here are the violations that ``black`` produces:
-
-- Quotes: for some reasons ``black`` uses ``"``
-  that almost no one uses in the ``python`` world
-- Trailing commas: ``black`` strips trailing commas and this makes
-  adding new code harder to review, since your ``git diff`` is polluted
-  by a comma change, the sad thing that trailing commas as a best-practice
-  are quite popular in ``python`` code
-- Line length. Violating rules by 10%-15% is not ok.
-  You either violate them or not. ``black`` violates line-length rules.
-
-And there's no configuration to fix it!
-Shame, that official ``python-org`` product violates the community standards
-and not enforcing them.
+Is supported since ``1.0.0``, but we recommend to use ``ruff format`` instead.

docs/pages/usage/integrations/github-actions.rst

@@ -29,10 +29,11 @@ We support three reporting options:
 - ``terminal`` (default one) when we just dump the output into Action's logs.
   Is the easiest one to setup, that's why we use it by default
 - ``github-pr-review`` (recommended) when we use `inline comments <https://github.com/reviewdog/reviewdog#reporter-github-pullrequest-review-comment--reportergithub-pr-review>`_ inside code reviews
-- ``github-pr-check`` when we use `Github Checks <https://github.com/reviewdog/reviewdog#reporter-github-checks--reportergithub-pr-check>`_ for the output
+- ``github-pr-check`` when we use `GitHub Checks <https://github.com/reviewdog/reviewdog#reporter-github-checks--reportergithub-pr-check>`_ for the output
+- ``github-check`` another way to use `GitHub Checks <https://github.com/reviewdog/reviewdog?tab=readme-ov-file#reporter-github-checks--reportergithub-check>`_ for the output
 
-Take a note that ``github-pr-review`` and ``github-pr-check`` requires
-``GITHUB_TOKEN`` environment variable to be set.
+Take a note that ``github-check``, ``github-pr-review`` and ``github-pr-check``
+requires ``GITHUB_TOKEN`` environment variable to be set.
 
 Default reporter looks like so:
 
@@ -64,6 +65,29 @@ We also support custom ``path`` to be specified:
     with:
       path: './your/custom/path'
 
+.. rubric:: cwd
+
+We also support custom ``cwd`` to be specified,
+it will be used to ``cd`` into before any other actions.
+It can be a custom subfolder with your configuration, etc.
+
+.. code:: yaml
+
+  - name: wemake-python-styleguide
+    uses: wemake-services/wemake-python-styleguide
+    with:
+      cwd: './your/custom/path'
+
+.. rubric:: fail_workflow
+
+Option which can be set to ``false`` with ``fail_workflow: false`` not
+to fail the workflow even if violations were found.
+
+.. rubric:: filter_mode
+
+Can be used to find only new violations and ignore old ones.
+See https://github.com/reviewdog/reviewdog?tab=readme-ov-file#filter-mode
+
 Outputs
 ~~~~~~~
 

docs/pages/usage/integrations/index.rst

@@ -9,6 +9,5 @@
   github-actions.rst
   ci.rst
   stubs.rst
-  pylint.rst
   extras.rst
   jupyter_notebooks.rst