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 }
 

docs/pages/guides/style.md

@@ -111,7 +111,7 @@ Here is the snippet to add the formatter to your `.pre-commit-config.yml`
 
 ```yaml
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: "v0.7.4"
+  rev: "v0.8.2"
   hooks:
     #  id: ruff would go here if using both
     - id: ruff-format
@@ -201,7 +201,7 @@ pre-commit hook.
 
 ```yaml
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: "v0.7.4"
+  rev: "v0.8.2"
   hooks:
     - id: ruff
       args: ["--fix", "--show-fixes"]
@@ -745,7 +745,7 @@ following pre-commit config:
 
 ```yaml
 - repo: https://github.com/pre-commit/mirrors-clang-format
-  rev: "v19.1.3"
+  rev: "v19.1.4"
   hooks:
     - id: clang-format
       types_or: [c++, c, cuda]
@@ -774,7 +774,7 @@ number of different file types. An example of usage:
 
 ```yaml
 - 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]
@@ -822,7 +822,7 @@ schemas, and you can load them via URL. It work on JSON, YAML, and TOML.
 
 ```yaml
 - repo: https://github.com/python-jsonschema/check-jsonschema
-  rev: "0.29.4"
+  rev: "0.30.0"
   hooks:
     - id: check-dependabot
     - id: check-github-workflows

docs/pages/guides/tasks.md

@@ -320,7 +320,7 @@ You can install `uv` with `pipx`, `brew`, etc. If you want to use uv in GitHub
 Actions, one way is to use this:
 
 ```yaml
-- uses: astral-sh/setup-uv@v3
+- uses: astral-sh/setup-uv@v4
 ```
 
 Check your jobs with `uv`; most things do not need to change. The main

docs/pages/index.md

@@ -17,10 +17,11 @@ maintainable, reusable, and shareable form? Start at the
 [tutorial]({% link pages/tutorials/index.md %}).
 
 **Learn recommended tools and best practices.** [Topical guides]({% link
-pages/guides/index.md %}) provide task-based instruction on topics that scientists
-and research software engineers may encounter as their projects evolve and grow.
-This covers modern packaging ([simple][] or [compiled][]), [style checking][],
-[testing][], [documentation][], [static typing][], [CI][], and much more!
+pages/guides/index.md %}) provide task-based instruction on topics that
+scientists and research software engineers may encounter as their projects
+evolve and grow. This covers modern packaging ([simple][] or [compiled][]),
+[style checking][], [testing][], [documentation][], [static typing][], [CI][],
+and much more!
 
 {: .highlight-title }
 
@@ -35,8 +36,8 @@ This covers modern packaging ([simple][] or [compiled][]), [style checking][],
 > 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.
 
 **Learn to write better research code.** A high-level document on
 [principles]({% link pages/principles/index.md %}) provides advice based on the

docs/pages/principles/design.md

@@ -24,9 +24,9 @@ test, maintain when data formats change, or reuse for unforeseen applications.
 
 ## Duck typing is a good idea
 
-[Duck typing][] treats objects based on what they can _do_, not based on what type
-they _are_. "If it walks like a duck and it quacks like a duck, then it must be a
-duck."
+[Duck typing][] treats objects based on what they can _do_, not based on what
+type they _are_. "If it walks like a duck and it quacks like a duck, then it
+must be a duck."
 
 Python in general and scientific Python in particular leverage _interfaces_
 (also known as Protocols) to support interoperability and reuse. For example, it

docs/pages/principles/index.md

@@ -9,9 +9,9 @@ has_children: true
 # Principles
 
 These pages are focused on designing good software, with a focus on end-user
-research code. [Process recommendations][] discusses the process of writing software,
-and [Design recommendations][] covers some tips about writing easy to read and
-maintain code.
+research code. [Process recommendations][] discusses the process of writing
+software, and [Design recommendations][] covers some tips about writing easy to
+read and maintain code.
 
 <!-- prettier-ignore-start -->
 

docs/pages/tutorials/module.md

@@ -18,9 +18,9 @@ In this section you will:
 ## Module
 
 As a concrete example, let's suppose we have a simple function that encodes
-[Snell's Law][]. Perhaps this function currently lives in a Jupyter notebook or a
-`.py` file in an email attachment. We want to put into some more lasting, maintainable,
-reusable, and/or shareable form.
+[Snell's Law][]. Perhaps this function currently lives in a Jupyter notebook or
+a `.py` file in an email attachment. We want to put into some more lasting,
+maintainable, reusable, and/or shareable form.
 
 Here is the code:
 
@@ -64,8 +64,8 @@ is extremely useful for collaborators, and the most common collaborator is
 Future You! It also includes type hints; this tells a programmer, type checker,
 or IDE what types are expected in an out of the function.
 
-Further, by following the [numpydoc standard][], we will be able to automatically
-generate nice-looking HTML documentation later. Notable features:
+Further, by following the [numpydoc standard][], we will be able to
+automatically generate nice-looking HTML documentation later. Notable features:
 
 - At the top, there is a succinct, one-line summary of the function's purpose.
   It must one line.

docs/pages/tutorials/packaging.md

@@ -32,9 +32,9 @@ cd example
 
 You should immediately initialize an empty Git repository in this directory; if
 you need a refresher on using Git for version control, check out the Software
-Carpentry lesson [Version Control with Git][]. You should commit changes regularly
-throughout what follows. This tutorial will not explicitly remind you to commit your
-work after this point.
+Carpentry lesson [Version Control with Git][]. You should commit changes
+regularly throughout what follows. This tutorial will not explicitly remind you
+to commit your work after this point.
 
 ```bash
 git init

docs/pages/tutorials/test.md

@@ -146,8 +146,8 @@ include:
 - `-k EXPRESSION` Filter tests by pattern-matching test name.
 - `--lf` Run only tests that failed on the previous run (**l**ast **f**ail).
 
-Consult the [pytest documentation][] for more. For more advanced pytest suggestions,
-see our [pytest guide][].
+Consult the [pytest documentation][] for more. For more advanced pytest
+suggestions, see our [pytest guide][].
 
 <!-- prettier-ignore-start -->
 

{{cookiecutter.project_name}}/.github/workflows/ci.yml

@@ -74,6 +74,6 @@ jobs:
           --durations=20
 
       - name: Upload coverage report
-        uses: codecov/codecov-action@v5.0.2
+        uses: codecov/codecov-action@v5.1.1
         with:
           token: {% raw %}${{ secrets.CODECOV_TOKEN }}{% endraw %}

{{cookiecutter.project_name}}/.github/workflows/{% if cookiecutter.__type!='compiled' %}cd.yml{% endif %}

@@ -49,7 +49,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/*"