Maintenance cleanup (#457)

Author: blink1073

.github/workflows/test.yml

@@ -46,7 +46,7 @@ jobs:
       fail-fast: false
       matrix:
         os: [ubuntu-latest, windows-latest, macos-latest]
-        python-version: ["3.8", "3.10"]
+        python-version: ["3.8", "3.11"]
     steps:
       - uses: actions/checkout@v2
       - uses: jupyterlab/maintainer-tools/.github/actions/base-setup@v1

.pre-commit-config.yaml

@@ -28,16 +28,24 @@ repos:
         files: \.py$
         args: [--profile=black]
 
-  - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: v3.0.0-alpha.3
+  - repo: https://github.com/abravalheri/validate-pyproject
+    rev: v0.10.1
     hooks:
-      - id: prettier
+      - id: validate-pyproject
+        stages: [manual]
+
+  - repo: https://github.com/executablebooks/mdformat
+    rev: 0.7.16
+    hooks:
+      - id: mdformat
+        additional_dependencies:
+          [mdformat-gfm, mdformat-frontmatter, mdformat-footnote]
 
   - repo: https://github.com/asottile/pyupgrade
     rev: v3.1.0
     hooks:
       - id: pyupgrade
-        args: [--py37-plus]
+        args: [--py38-plus]
 
   - repo: https://github.com/john-hen/Flake8-pyproject
     rev: 1.1.0.post0

docs/source/get_started/making_release_from_releaser.md

@@ -11,9 +11,13 @@ already uses Jupyter Releaser.
 ## Set up
 
 - Fork `jupyter_releaser`
+
 - Generate a [GitHub Access token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with access to target GitHub repo to run GitHub Actions
+
 - Add the token as `ADMIN_GITHUB_TOKEN` in the [repository secrets](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository) of your fork. The token must have `repo` and `workflow` scopes.
+
 - If the repo generates PyPI release(s), create a scoped PyPI [token](https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github). We recommend using a scoped token for security reasons.
+
 - You can store the token as `PYPI_TOKEN` in your fork's `Secrets`.
 
   - Advanced usage: if you are releasing multiple repos, you can create a secret named `PYPI_TOKEN_MAP` instead of `PYPI_TOKEN` that is formatted as follows:
@@ -35,8 +39,11 @@ already uses Jupyter Releaser.
 ## Prep Release
 
 - Go to the "Actions" tab in your fork of `jupyter_releaser`
+
 - Select the "Step 1: Prep Release" workflow on the left
+
 - Click on the "Run workflow" dropdown button on the right
+
 - Fill in the appropriate parameters
 
   ![Prep Release Workflow Dialog](../images/prep_release.png)
@@ -62,29 +69,40 @@ already uses Jupyter Releaser.
   ![Draft GitHub Release](../images/draft_github_release.png)
 
 - Review the contents, fixing typos or otherwise editing as necessary.
+
 - If there is a section called "Other Merged PRs", it means those PRs did not have one of the appropriate labels. If desired, you can go label those PRs and then re-run the workflow, or move the entries manually to the desired section. The appropriate labels are: bug, maintenance, enhancement, feature, and documentation.
 
 ## Publish Release
 
 - Return to your fork of `jupyter_releaser`
+
 - Click on the "Actions" tab
+
 - Select the "Publish Release" workflow on the left
+
 - Click on the "Run workflow" button on the right
+
 - Fill in the target repository
+
 - (Optional) Fill in draft GitHub Release URL given by the Changelog PR.
   If you leave it blank it will use the most recent draft GitHub release.
 
   ![Publish Release Workflow Dialog](../images/publish_release.png)
 
 - The workflow will finish the GitHub release and publish assets to the appropriate registries.
+
 - If the workflow is not targeting the default branch, it will also generate a forward-port pull request for the changelog entry to the default branch.
+
 - When the workflow finishes it will print a link to the GitHub release and the forward-port PR (if appropriate) in the "\*\* Next Step \*\*" output.
 
   ![Publish Release Workflow Next Step](../images/publish_release_next_step.png)
 
 - **Note** If the publish portion fails you can attempt to publish the draft GitHub release given by the URL in the "\*\* Failure Message \*\*" using the "Publish Release" workflow again. It will skip past the asset creation phase
   and move into asset publish.
+
 - **Note** GitHub Actions caches the secrets used on a given workflow run. So if you run into an auth issue, you'll
   need to run a new workflow instead of re-running the existing workflow.
+
 - Review and merge the forward-port PR if applicable
+
 - Announce the release on appropriate channels

docs/source/get_started/making_release_from_repo.md

@@ -11,22 +11,31 @@ already uses Jupyter Releaser using workflows on its own repository.
 ## Prep Release
 
 - Go to the "Actions" tab in the repository.
+
 - Select the "Step 1: Prep Release" workflow on the left
+
 - Click on the "Run workflow" dropdown button on the right
+
 - Fill in the appropriate parameters
 
   ![Prep Release Workflow Dialog](../images/prep_release_repo.png)
 
 - The "New Version Spec" will usually be the full version (e.g. 0.7.1). Repos using `tbump` can also use:
+
   - "next" or "patch" option, which will bump the micro version (or the build version in the case of a prerelease).
     Note: The "next" and "patch" options are not available when using dev versions, you must use explicit versions
     instead.
   - "minor" option, which will bump to the next minor version directly.
   - "release" option, which will start making prereleases (a0, a1...)
+
 - Use the "since" field to select PRs prior to the latest tag to include in the release
+
 - Type "true" in the "since the last stable git tag" if you would like to include PRs since the last non-prerelease version tagged on the target repository and branch.
+
 - The additional "Post Version Spec" field should be used if your repo uses a dev version (e.g. 0.7.0.dev0)
+
 - The workflow will use the GitHub API to find the relevant pull requests and make an appropriate changelog entry.
+
 - The workflow will create a draft GitHub release to the target
   repository and branch, with the draft changelog contents.
 
@@ -39,27 +48,36 @@ already uses Jupyter Releaser using workflows on its own repository.
   ![Draft GitHub Release](../images/draft_github_release.png)
 
 - Review the contents, fixing typos or otherwise editing as necessary.
+
 - If there is a section called "Other Merged PRs", it means those PRs did not have one of the appropriate labels. If desired, you can go label those PRs and then re-run the workflow, or move the entries manually to the desired section. The appropriate labels are: bug, maintenance, enhancement, feature, and documentation.
 
 ## Publish Release
 
 - Return to "Actions" tab for the repository
+
 - Select the "Publish Release" workflow on the left
+
 - Click on the "Run workflow" button on the right
+
 - (Optional) Fill in draft GitHub Release URL given by the Changelog PR.
   If you leave it blank it will use the most recent draft GitHub release.
 
   ![Publish Release Workflow Dialog](../images/publish_release_repo.png)
 
 - The workflow will finish the GitHub release and publish assets to the appropriate registries.
+
 - If the workflow is not targeting the default branch, it will also generate a forward-port pull request for the changelog entry to the default branch.
+
 - When the workflow finishes it will print a link to the GitHub release and the forward-port PR (if appropriate) in the "\*\* Next Step \*\*" output.
 
   ![Publish Release Workflow Next Step](../images/publish_release_next_step.png)
 
 - **Note** If the publish portion fails you can attempt to publish the draft GitHub release given by the URL in the "\*\* Failure Message \*\*" using the "Publish Release" workflow again. It will skip past the asset creation phase
   and move into asset publish.
+
 - **Note** GitHub Actions caches the secrets used on a given workflow run. So if you run into an auth issue, you'll
   need to run a new workflow instead of re-running the existing workflow.
+
 - Review and merge the forward-port PR if applicable
+
 - Announce the release on appropriate channels

docs/source/how_to_guides/convert_repo_from_releaser.md

@@ -17,13 +17,15 @@ See checklist below for details:
 A. Prep the `jupyter_releaser` fork:
 
 - [ ] Clone this repository onto your GitHub user account.
+
 - [ ] Add a GitHub [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with access to target GitHub repo to run
-      GitHub Actions, saved as `ADMIN_GITHUB_TOKEN` in the
-      [repository secrets](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository).
-      The token will need "public_repo", and "repo:status" permissions.
+  GitHub Actions, saved as `ADMIN_GITHUB_TOKEN` in the
+  [repository secrets](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository).
+  The token will need "public_repo", and "repo:status" permissions.
+
 - [ ] Add access token for the [PyPI registry](https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github) stored as `PYPI_TOKEN`.
-      _Note_ For security reasons, it is recommended that you scope the access
-      to a single repository, and use a variable called `PYPI_TOKEN_MAP` that is formatted as follows:
+  _Note_ For security reasons, it is recommended that you scope the access
+  to a single repository, and use a variable called `PYPI_TOKEN_MAP` that is formatted as follows:
 
   ```text
   owner1/repo1,token1
@@ -47,7 +49,7 @@ B. Prep target repository:
   - Note that [directives](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#syntax-directives) can still be used
 - [ ] Add HTML start and end comment markers to Changelog file - see example in [CHANGELOG.md](https://github.com/jupyter-server/jupyter_releaser/blob/main/CHANGELOG.md) (view in raw mode)
 - [ ] We recommend using [hatch](https://hatch.pypa.io/latest/) for your
-      build system and for version handling.
+  build system and for version handling.
   - If previously providing `version_info` like `version_info = (1, 7, 0, '.dev', '0')`, use a pattern like the one below in your version file:
 
 ```toml
@@ -94,7 +96,7 @@ version_info = tuple(parts)
 ````
 
 - [ ] Add a workflow that uses the [`enforce-label`](https://github.com/jupyterlab/maintainer-tools#enforce-labels) action from `jupyterlab/maintainer-tools` to ensure that all PRs have on of the triage labels used to
-      categorize the changelog.
+  categorize the changelog.
 
 - [ ] Update or add `RELEASE.md` that describes the onboarding and release process, e.g. [jupyter_server](https://github.com/jupyter-server/jupyter_server/blob/main/RELEASE.md).
 

docs/source/how_to_guides/convert_repo_from_repo.md

@@ -4,7 +4,7 @@ Follow the steps below to convert a repository to use Jupyter Releaser for relea
 
 ## Prerequisites
 
-See [hecklist below for details:
+See \[hecklist below for details:
 
 - Markdown changelog
 - Bump version configuration (if using Python), for example [hatch](https://hatch.pypa.io/latest/)
@@ -15,28 +15,28 @@ See [hecklist below for details:
 ## Checklist for Adoption
 
 - [ ] Add a GitHub [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token), preferably from a "machine user" GitHub
-      account that has admin access to the repository. The token itself will
-      need "public_repo", and "repo:status" permissions. Save the token as
-      `ADMIN_GITHUB_TOKEN`
-      in the [repository secrets](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository). We need this
-      access token to allow for branch protection rules, which block the pushing
-      of commits when using the `GITHUB_TOKEN`, even when run from an admin user
-      account.
+  account that has admin access to the repository. The token itself will
+  need "public_repo", and "repo:status" permissions. Save the token as
+  `ADMIN_GITHUB_TOKEN`
+  in the [repository secrets](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository). We need this
+  access token to allow for branch protection rules, which block the pushing
+  of commits when using the `GITHUB_TOKEN`, even when run from an admin user
+  account.
 - [ ] Add access token for the [PyPI registry](https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github) stored as `PYPI_TOKEN`.
-      _Note_ For security reasons, it is recommended that you scope the access
-      to a single repository. Additionally, this token should belong to a
-      machine account and not a user account.
+  _Note_ For security reasons, it is recommended that you scope the access
+  to a single repository. Additionally, this token should belong to a
+  machine account and not a user account.
 - [ ] If needed, add access token for [npm](https://docs.npmjs.com/creating-and-viewing-access-tokens), saved as `NPM_TOKEN`. Again this should
-      be created using a machine account that only has publish access.
+  be created using a machine account that only has publish access.
 - [ ] Ensure that only trusted users with 2FA have admin access to the
-      repository, since they will be able to trigger releases.
+  repository, since they will be able to trigger releases.
 - [ ] Switch to Markdown Changelog
   - We recommend [MyST](https://myst-parser.readthedocs.io/en/latest/?badge=latest), especially if some of your docs are in reStructuredText.
   - Can use `pandoc -s changelog.rst -o changelog.md` and some hand edits as needed.
   - Note that [directives](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#syntax-directives) can still be used
 - [ ] Add HTML start and end comment markers to Changelog file - see example in [CHANGELOG.md](https://github.com/jupyter-server/jupyter_releaser/blob/main/CHANGELOG.md) (view in raw mode)
 - [ ] We recommend using [hatch](https://hatch.pypa.io/latest/) for your
-      build system and for version handling.
+  build system and for version handling.
   - If previously providing `version_info` like `version_info = (1, 7, 0, '.dev', '0')`, use a pattern like the one below in your version file:
 
 ```toml
@@ -81,7 +81,7 @@ version_info = tuple(parts)
 ```
 
 - [ ] Add a workflow that uses the [`enforce-label`](https://github.com/jupyterlab/maintainer-tools#enforce-labels) action from `jupyterlab/maintainer-tools` to ensure that all PRs have on of the triage labels used to
-      categorize the changelog.
+  categorize the changelog.
 
 - [ ] Update or add `RELEASE.md` that describes the onboarding and release process, e.g. [jupyter_server](https://github.com/jupyter-server/jupyter_server/blob/main/RELEASE.md).
 
@@ -96,7 +96,7 @@ version_info = tuple(parts)
 - [ ] Try out the `Prep Release` and `Publish Release` process against a fork of the target repo first so you don't accidentally push tags and GitHub releases to the source repository. Set the `TWINE_REPOSITORY_URL` environment variable to `https://test.pypi.org/legacy/` in the "Finalize Release" action part of the workflow
 
 - [ ] Try the `Publish Release` process using a prerelease version on the main
-      repository before publishing a final version.
+  repository before publishing a final version.
 
 ## Backport Branches
 

pyproject.toml

@@ -17,6 +17,7 @@ classifiers = [
     "Programming Language :: Python :: 3.8",
     "Programming Language :: Python :: 3.9",
     "Programming Language :: Python :: 3.10",
+    "Programming Language :: Python :: 3.11",
 ]
 urls = {Homepage = "https://jupyter.org"}
 requires-python = ">=3.8"