fix: broken raw / badges in a few places

Assisted-by: CopilotCLI:claude-hauku-4.5
Signed-off-by: Henry Schreiner <henryfs@princeton.edu>

Author: henryiii

docs/_partials/pyproject.md

@@ -138,7 +138,7 @@ forward) and they are more composable. In contrast with extras,
 dependency-groups are not available when installing your package via PyPI, but
 they are available for local installation (and can be installed separately from
 your package); the `dev` group is even installed, by default, when using `uv`'s
-high level commands like `uv run` and `uv sync`. {% rr PP0086 %} Here is an
+high level commands like `uv run` and `uv sync`. {rr}`PP006` Here is an
 example:
 
 <!-- [[[cog

docs/pages/guides/gha_basic.md

@@ -100,8 +100,6 @@ adjust the Python versions to suit your taste; you can also test on different
 OS's if you'd like by adding them to the matrix and inputting them into
 `runs-on`.
 
-{% raw %}
-
 ```yaml
 tests:
   runs-on: ubuntu-latest
@@ -131,8 +129,6 @@ tests:
       run: uv run pytest
 ```
 
-{% endraw %}
-
 A few things to note from above:
 
 The matrix should contain the versions you are interested in. You can also test
@@ -229,15 +225,11 @@ actions have outputs, and bash actions can manually write to output:
   run: echo "something=true" >> $GITHUB_OUTPUT
 ```
 
-{% raw %}
-
 You can now refer to this step in a later step with
 `${{ steps.someid.something }}`. You also can get it from another job by using
 `${{ needs.<jobname>.outputs.something }}`. The `toJson()` function is useful
 for inputting JSON - you can even generate matrices dynamically this way!
 
-{% endraw %}
-
 #### Pretty output
 
 You can write GitHub flavored markdown to `$GITHUB_STEP_SUMMARY`, and it will be
@@ -342,16 +334,12 @@ These are some things you might need.
 {rr}`GH102` If you add the following, you can ensure only one run per
 PR/branch happens at a time, cancelling the old run when a new one starts:
 
-{% raw %}
-
 ```yaml
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
 ```
 
-{% endraw %}
-
 Anything with a matching group name will count in the same group - the ref is
 the "from" name for the PR. If you want, you can replace `github.ref` with
 `github.event.pull_request.number || github.sha`; this will still cancel on PR
@@ -368,8 +356,6 @@ pass).
 
 As an example, if you had `lint` and `checks` jobs, use this:
 
-{% raw %}
-
 ```yaml
 pass:
   if: always()
@@ -381,8 +367,6 @@ pass:
         jobs: ${{ toJSON(needs) }}
 ```
 
-{% endraw %}
-
 We want the job to always run, so we set `if: always()`. Otherwise, it might be
 skipped if any job it depends on is skipped, and skipped jobs count as "passing"
 to GitHub's automerge (yikes!). The important part of the job is the `needs:`
@@ -441,8 +425,6 @@ ideally shouldn't change the user's environment; suddenly changing the active
 Python version might come as a surprise. You can do that, though, using
 `update-environment: false` with `setup-python` and `pipx`:
 
-{% raw %}
-
 ```yaml
 - uses: actions/setup-python@v6
   id: python
@@ -457,8 +439,6 @@ Python version might come as a surprise. You can do that, though, using
     github.action_path }}' ${{ inputs.some-input }}
 ```
 
-{% endraw %}
-
 You use the `python-path` output from `setup-python` to get the Python you
 activated. You use `github.action_path` to get the path to the checked-out
 action.
@@ -510,8 +490,6 @@ on:
 Otherwise, they look like normal workflows. Then you need another reusable
 workflow file to decide when to run a specific situation.
 
-{% raw %}
-
 ```yaml
 # reusable-change-detection.yml
 on:
@@ -522,17 +500,13 @@ on:
       # More here if you have more situations to detect
 ```
 
-{% endraw %}
-
 You start by specifying outputs when running this. You'll want one output per
 situation you want to detect. The value will be output from our
 `change-detection` job below, and defaults to "false" if we don't output
 anything.
 
 Now, we need our job:
 
-{% raw %}
-
 ```yaml
 jobs:
   change-detection:
@@ -566,8 +540,6 @@ jobs:
       # Add 2 more steps per situation you have to detect
 ```
 
-{% endraw %}
-
 This has a bit of boilerplate (mostly around passing variables around), but what
 it's doing is fairly simple. Instead of stepping through it, let's look at what
 it's trying to do. First, you need to find a list of all changed files in the
@@ -595,8 +567,6 @@ If you have more situations, you just repeat these two steps with different
 Finally, you write the overarching CI workflow that combines the reusable
 workflows, something like `ci.yml`:
 
-{% raw %}
-
 ```yaml
 on:
   workflow_dispatch:
@@ -642,8 +612,6 @@ If you have more situations, add another `${{ ... }}` above, after the first
 one, and add them to the needs list. This is really just injecting "tests" only
 if the "tests" job is being skipped into `allowed-skips`.
 
-{% endraw %}
-
 :::{tip}
 Some examples of repos using this method are:
 
@@ -690,16 +658,12 @@ configure Pages.
   uses: actions/configure-pages@v6
 ```
 
-{% raw %}
-
 Notice this action sets an `id:`; this will allow you to use the outputs from
 this action later; specifically, may want to use
 `${{ steps.pages.outputs.base_path }}` when building (you can also get `origin`,
 `base_url`, or `host` - see the action
 [config](https://github.com/actions/configure-pages/blob/main/action.yml)).
 
-{% endraw %}
-
 ```yaml
 - name: Upload artifact
   uses: actions/upload-pages-artifact@v5
@@ -712,8 +676,6 @@ Finally, you'll need to deploy the artifact (named `github-pages`) to Pages. You
 can make this a custom job with `needs:` pointing at your previous job (in this
 example, the previous job is called `build`):
 
-{% raw %}
-
 ```yaml
 deploy:
   environment:
@@ -727,8 +689,6 @@ deploy:
       uses: actions/deploy-pages@v5
 ```
 
-{% endraw %}
-
 The deploy-pages job gives a `page_url`, which is the same as `base_url` on the
 configure step, and can be set in the `environment`. If you want to do
 everything in one job, you only need one of these.

docs/pages/guides/gha_pure.md

@@ -58,8 +58,6 @@ the name "CI/CD", you can just combine the two `on` dicts.
 
 ### Distribution: Pure Python wheels
 
-{% raw %}
-
 ```yaml
 dist:
   runs-on: ubuntu-latest
@@ -80,8 +78,6 @@ dist:
       run: pipx run twine check 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.
@@ -129,7 +125,6 @@ recommended {rr}`GH105`:
 ::::{tab-set}
 :::{tab-item} Trusted Publishing (recommended)
 :sync: trusted-publishing
-{% raw %}
 
 ```yaml
 publish:
@@ -155,8 +150,6 @@ publish:
     - uses: pypa/gh-action-pypi-publish@release/v1
 ```
 
-{% endraw %}
-
 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
@@ -168,7 +161,6 @@ that the artifacts were built on your actions.
 :::
 :::{tab-item} Token
 :sync: token
-{% raw %}
 
 ```yaml
 publish:
@@ -186,8 +178,6 @@ publish:
         password: ${{ secrets.pypi_password }}
 ```
 
-{% endraw %}
-
 If you cannot use Trusted Publishing, this publishes to PyPI with a token.
 You'll need to go to PyPI, generate a token for your user, and put it into
 `pypi_password` on your repo's secrets page. Once you have a project, you should
@@ -204,7 +194,6 @@ interface:
 ::::{tab-set}
 :::{tab-item} Trusted Publishing (recommended)
 :sync: trusted-publishing
-{% raw %}
 
 ```yaml
 name: CD
@@ -253,11 +242,9 @@ jobs:
       - uses: pypa/gh-action-pypi-publish@release/v1
 ```
 
-{% endraw %}
 :::
 :::{tab-item} Token
 :sync: token
-{% raw %}
 
 ```yaml
 name: CD
@@ -298,8 +285,6 @@ jobs:
           password: ${{ secrets.pypi_password }}
 ```
 
-{% endraw %}
-
 If you cannot use Trusted Publishing, this publishes to PyPI with a token.
 You'll need to go to PyPI, generate a token for your user, and put it into
 `pypi_password` on your repo's secrets page. Once you have a project, you should

docs/pages/guides/gha_wheels.md

@@ -93,8 +93,6 @@ with `pipx run build==<version>`.
 
 The core of the work is down here:
 
-{% raw %}
-
 ```yaml
 build_wheels:
   name: Wheel on ${{ matrix.os }}
@@ -127,8 +125,6 @@ build_wheels:
         path: wheelhouse/*.whl
 ```
 
-{% endraw %}
-
 There are several things to note here. First, one of the reasons this works is
 because you followed the suggestions in the previous sections, and your package
 builds nicely into a wheel without strange customizations (if you _really_ need
@@ -164,7 +160,6 @@ Trusted Publishing is more secure and recommended {rr}`GH105`:
 ::::{tab-set}
 :::{tab-item} Trusted Publishing (recommended)
 :sync: trusted-publishing
-{% raw %}
 
 ```yaml
 upload_all:
@@ -192,8 +187,6 @@ upload_all:
     - uses: pypa/gh-action-pypi-publish@release/v1
 ```
 
-{% endraw %}
-
 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
@@ -205,7 +198,6 @@ that the artifacts were built on your actions.
 :::
 :::{tab-item} Token
 :sync: token
-{% raw %}
 
 ```yaml
 upload_all:
@@ -224,8 +216,6 @@ upload_all:
         password: ${{ secrets.pypi_password }}
 ```
 
-{% endraw %}
-
 If you cannot use Trusted Publishing, this publishes to PyPI with a token.
 You'll need to go to PyPI, generate a token for your user, and put it into
 `pypi_password` on your repo's secrets page. Once you have a project, you should

docs/pages/guides/packaging_classic.md

@@ -184,8 +184,6 @@ computed correctly from a checkout that is too shallow. For GitHub Actions, use
 For GitHub actions, you can add a few lines that will enable you to manually
 trigger builds with custom versions:
 
-{% raw %}
-
 ```yaml
 on:
   workflow_dispatch:
@@ -196,8 +194,6 @@ env:
   SETUPTOOLS_SCM_PRETEND_VERSION: ${{ github.event.inputs.overrideVersion }}
 ```
 
-{% endraw %}
-
 If you fill in the override version setting when triggering a manual workflow
 run, that version will be forced, otherwise, it works as normal.