chore(deps): bump versions (#522)

* [create-pull-request] automated change

* style: pre-commit fixes

---------

Co-authored-by: scientific-python-pr-tokenbot[bot] <181030687+scientific-python-pr-tokenbot[bot]@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

Author: scientific-python-pr-tokenbot[bot]

.pre-commit-config.yaml

@@ -29,7 +29,7 @@ repos:
         additional_dependencies: [black==24.*]
 
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: "v0.7.4"
+    rev: "v0.8.2"
     hooks:
       - id: ruff
         args: ["--fix", "--show-fixes"]
@@ -59,7 +59,7 @@ repos:
           - types-PyYAML
 
   - repo: https://github.com/rbubley/mirrors-prettier
-    rev: "v3.3.3"
+    rev: "v3.4.2"
     hooks:
       - id: prettier
         types_or: [yaml, markdown, html, css, scss, javascript, json]

README.md

@@ -39,10 +39,10 @@ During generation you can select from the following backends for your package:
 1. [hatch][]: This uses hatchling, a modern builder with nice file inclusion,
    extendable via plugins, and good error messages. **(Recommended for pure
    Python projects)**
-2. [flit][]: A modern, lightweight [PEP 621][] build system for pure Python projects.
-   Replaces setuptools, no MANIFEST.in, setup.py, or setup.cfg. Low learning curve.
-   Easy to bootstrap into new distributions. Difficult to get the right files included,
-   little dynamic metadata support.
+2. [flit][]: A modern, lightweight [PEP 621][] build system for pure Python
+   projects. Replaces setuptools, no MANIFEST.in, setup.py, or setup.cfg. Low
+   learning curve. Easy to bootstrap into new distributions. Difficult to get
+   the right files included, little dynamic metadata support.
 3. [pdm][]: A modern, less opinionated all-in-one solution to pure Python
    projects supporting standards. Replaces setuptools, venv/pipenv, pip, wheel,
    and twine. Supports [PEP 621][].
@@ -57,8 +57,8 @@ During generation you can select from the following backends for your package:
 7. [scikit-build][]: A scikit-build (CMake) project also using pybind11, using
    scikit-build-core. **(Recommended for C++ projects)**
 8. [meson-python][]: A Meson project also using pybind11. (No VCS versioning)
-9. [maturin][]: A [PEP 621][] builder for Rust binary extensions. (No VCS versioning)
-   **(Recommended for Rust projects)**
+9. [maturin][]: A [PEP 621][] builder for Rust binary extensions. (No VCS
+   versioning) **(Recommended for Rust projects)**
 
 Currently, the best choice is probably hatch for pure Python projects, and
 scikit-build (such as the scikit-build-core + pybind11 choice) for binary
@@ -218,8 +218,8 @@ A lot of the guide, cookiecutter, and repo-review started out as part of
 
 <!-- sp-repo-review -->
 
-`sp-repo-review` provides checks based on the [Scientific-Python
-Development Guide][] at [scientific-python/cookie][] for [repo-review][].
+`sp-repo-review` provides checks based on the [Scientific-Python Development
+Guide][] at [scientific-python/cookie][] for [repo-review][].
 
 This tool can check the style of a repository. Use like this:
 

docs/pages/guides/coverage.md

@@ -91,7 +91,7 @@ enough for a simple testing suite, can be written as follows:
 
 ```yaml
 - name: Upload coverage report
-  uses: codecov/codecov-action@v5.0.2
+  uses: codecov/codecov-action@v5.1.1
   with:
     token: ${{ secrets.CODECOV_TOKEN }}
 ```

docs/pages/guides/gha_pure.md

@@ -11,11 +11,11 @@ custom_title: GitHub Actions for pure Python wheels
 
 # GitHub Actions: Pure Python wheels
 
-We will cover binary wheels [on the next page][], but if you do not have a compiled
-extension, this is called a universal (pure Python) package, and the procedure to
-make a "built" wheel is simple. At the end of this page, there is a recipe that can
-often be used exactly for pure Python wheels (if the previous recommendations were
-followed).
+We will cover binary wheels [on the next page][], but if you do not have a
+compiled extension, this is called a universal (pure Python) package, and the
+procedure to make a "built" wheel is simple. At the end of this page, there is a
+recipe that can often be used exactly for pure Python wheels (if the previous
+recommendations were followed).
 
 {: .note }
 
@@ -89,8 +89,8 @@ dist:
 {% endraw %}
 
 We use [PyPA-Build](https://pypa-build.readthedocs.io/en/latest/), a new build
-tool designed to make building wheels and SDists easy. It run a [PEP 517][] backend
-and can get [PEP 518][] requirements even for making SDists.
+tool designed to make building wheels and SDists easy. It run a [PEP 517][]
+backend and can get [PEP 518][] requirements even for making SDists.
 
 By default this will make an SDist and a wheel from the package in the current
 directory, and they will be placed in `./dist`. You can only build SDist (`-s`),
@@ -154,7 +154,7 @@ publish:
         path: dist
 
     - name: Generate artifact attestation for sdist and wheel
-      uses: actions/attest-build-provenance@v1.4.4
+      uses: actions/attest-build-provenance@v2.0.1
       with:
         subject-path: "dist/*"
 
@@ -166,8 +166,8 @@ publish:
 When you make a GitHub release in the web UI, we publish to PyPI. You'll just
 need to tell PyPI which org, repo, workflow, and set the `pypi` environment to
 allow pushes from GitHub. If it's the first time you've published a package, go
-to the [PyPI trusted publisher docs] for instructions on preparing PyPI to accept
-your initial package publish.
+to the [PyPI trusted publisher docs] for instructions on preparing PyPI to
+accept your initial package publish.
 
 We are also generating artifact attestations, which can allow users to verify
 that the artifacts were built on your actions.
@@ -252,7 +252,7 @@ jobs:
           path: dist
 
       - name: Generate artifact attestation for sdist and wheel
-        uses: actions/attest-build-provenance@v1.4.4
+        uses: actions/attest-build-provenance@v2.0.1
         with:
           subject-path: "dist/*"
 

docs/pages/guides/gha_wheels.md

@@ -114,7 +114,7 @@ build_wheels:
         fetch-depth: 0
         submodules: true
 
-    - uses: pypa/cibuildwheel@v2.21
+    - uses: pypa/cibuildwheel@v2.22
 
     - name: Upload wheels
       uses: actions/upload-artifact@v4
@@ -178,7 +178,7 @@ upload_all:
         merge-multiple: true
 
     - name: Generate artifact attestations
-      uses: actions/attest-build-provenance@v1.4.4
+      uses: actions/attest-build-provenance@v2.0.1
       with:
         subject-path: "dist/*"
 
@@ -190,8 +190,8 @@ upload_all:
 When you make a GitHub release in the web UI, we publish to PyPI. You'll just
 need to tell PyPI which org, repo, workflow, and set the `pypi` environment to
 allow pushes from GitHub. If it's the first time you've published a package, go
-to the [PyPI trusted publisher docs] for instructions on preparing PyPI to accept
-your initial package publish.
+to the [PyPI trusted publisher docs] for instructions on preparing PyPI to
+accept your initial package publish.
 
 We are also generating artifact attestations, which can allow users to verify
 that the artifacts were built on your actions.

docs/pages/guides/index.md

@@ -18,9 +18,9 @@ for your `CONTRIBUTING.md`, and at least glance through other sections.
 Following that, there are recommendations for [style][], intended to promote
 good practices and to ensure continuity across the packages. There is a
 [dedicated page for static type checking with MyPy][mypy]. There is then a guide
-on [simple packaging][], [compiled packaging][], or even [classic packaging][], which
-should help in ensuring a consistent developer and user experience when working with
-distribution.
+on [simple packaging][], [compiled packaging][], or even [classic packaging][],
+which should help in ensuring a consistent developer and user experience when
+working with distribution.
 
 A section on CI follows, with a [general setup guide][gha_basic], and then two
 choices for using CI to distribute your package, on for [pure Python][gha_pure],
@@ -43,8 +43,8 @@ on setting up [docs][], as well.
 > Checking an existing project
 >
 > We provide [sp-repo-review][], a set of [repo-review][] checks for comparing
-> your repository with the guidelines, runnable [right in the guide][] via WebAssembly!
-> All checks point to a linked badge in the guide.
+> your repository with the guidelines, runnable [right in the guide][] via
+> WebAssembly! All checks point to a linked badge in the guide.
 
 <!-- prettier-ignore-start -->
 

docs/pages/guides/mypy.md

@@ -77,7 +77,8 @@ to a code base. By default:
 You can add configuration to `pyproject.toml` (and a little bit to the files
 themselves), or you can go all the way and pass `--strict`, which will turn on
 everything. Try to turn on as much as possible, and increase it until you can
-run with full `strict` checking. See the [style page][] for configuration suggestions.
+run with full `strict` checking. See the [style page][] for configuration
+suggestions.
 
 [style page]: {% link pages/guides/style.md %}
 

docs/pages/guides/packaging_classic.md

@@ -22,8 +22,8 @@ like [Hatch][] are drastically simpler - most of this page is unneeded for those
 systems. Even setuptools supports modern config now, though setup.py is still
 also required for compiled packages to be supported.
 
-Also see the [Python packaging guide][], especially the [Python
-packaging tutorial][].
+Also see the [Python packaging guide][], especially the [Python packaging
+tutorial][].
 
 {: .note }
 

docs/pages/guides/packaging_compiled.md

@@ -26,8 +26,8 @@ The most exciting developments have been new native build backends:
 
 {: .note }
 
-You should be familiar with [packing a pure
-Python project]({% link pages/guides/packaging_compiled.md %}) - the metadata
+You should be familiar with [packing a pure Python
+project]({% link pages/guides/packaging_compiled.md %}) - the metadata
 configuration is the same.
 
 There are also classic setuptools plugins:

docs/pages/guides/packaging_simple.md

@@ -13,11 +13,11 @@ parent: Topical Guides
 Python packages can now use a modern build system instead of the classic but
 verbose setuptools and `setup.py`. The one you select doesn't really matter that
 much; they all use a [standard configuration language][metadata] introduced in
-[PEP 621][]. The PyPA's Flit is a great option. [scikit-build-core][] and [meson-python][]
-are being developed to support this sort of configuration, enabling binary extension
-packages to benefit too. These [PEP 621][] tools currently include [Hatch][],
-[PDM][], [Flit][], and [Setuptools][]. [Poetry][] will eventually gain support
-in 2.0.
+[PEP 621][]. The PyPA's Flit is a great option. [scikit-build-core][] and
+[meson-python][] are being developed to support this sort of configuration,
+enabling binary extension packages to benefit too. These [PEP 621][] tools
+currently include [Hatch][], [PDM][], [Flit][], and [Setuptools][]. [Poetry][]
+will eventually gain support in 2.0.
 
 {: .note-title }