ruff is faster and handle everything we had prior.
isort configuration done based on the indication from
https://github.com/astral-sh/ruff/issues/4670, previousely based on
reorder-python-import (#11896)
flake8-docstrings was a wrapper around pydocstyle (now archived) that
explicitly asks to use ruff in https://github.com/PyCQA/pydocstyle/pull/658.
flake8-typing-import is useful mainly for project that support python 3.7
and the one useful check will be implemented in https://github.com/astral-sh/ruff/issues/2302
We need to keep blacken-doc because ruff does not handle detection
of python code inside .md and .rst. The direct link to the repo is
now used to avoid a redirection.
Manual fixes:
- Lines that became too long
- % formatting that was not done automatically
- type: ignore that were moved around
- noqa of hard to fix issues (UP031 generally)
- fmt: off and fmt: on that is not really identical
between black and ruff
- autofix re-order in pre-commit from faster to slower
Co-authored-by: Ran Benita <ran@unusedvar.com>
Setting `norecursedirs` overrides the default, so we end up scanning
dot-directories and such which slows down collection unnecessarily
(150ms on my working directory).
this issues is less likely to hit due to the recent regendoc release
which includes a wheel
* migrate to setuptools_scm 6.3.2
* use SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST
Now `tox -e docs` will also include the draft changelog for the
next version (locally only).
`CHANGELOG.rst` now only points to the changelog on READTHEDOCS so
sphinx diretives can be used.
Followup to https://github.com/pytest-dev/pytest/pull/6272
This creates a separate section from 'features' for small changes which
don't usually require user intervention, such as:
* Human readable session duration
* New junitxml fields
* Improved colors in terminal
* etc.
The idea is to better match user expectations about new actual
features in the "Features" section of the changelog.
I think it might sense to display in the CHANGELOG internal or
trivial changes because they might trip users between releases.
For example, a note about an internal refactoring (like
moving a class between modules) is useful for a user
that has been using the internal API. Of course
we are not breaking anything because it was an internal API, but no
reason not to save time for users who did use it.
