docs: fix typos and grammar

content/basic-packaging/01_setup.md

@@ -137,7 +137,7 @@ This is really fast, though it's completely empty (no pip). And it defaults to `
 
 We will be using `uv`, which can do a lot of this for us.
 
-[^1]: Distributions may strip it out and make it a separate intallable package.
+[^1]: Distributions may strip it out and make it a separate installable package.
 
 ### Requirements
 
@@ -152,7 +152,7 @@ But a virtual environment is meant to be expendable. You should be able to delet
 :::{card} Project (app)
 These are for making a virtual env. They don't affect libraries.
 
-- **requirement.txt**: Classic, very old format
+- **requirements.txt**: Classic, very old format
   - Basically a list of args to pass to `pip install`
 - **requirements.in**: Manual locking
   - You make a locked requirements.txt from this file
@@ -175,7 +175,7 @@ Most libraries also have developer environments, which follows the "Project
 
 > [!WARNING]
 > For historical reasons, `optional-dependencies` is sometimes used for
-> for these too; this is due to it pre-dating `dependency-groups`.
+> these too; this is due to it pre-dating `dependency-groups`.
 
 :::
 
@@ -245,7 +245,7 @@ This special property allows us to do something interesting. Imagine we:
 
 1. Made a venv somewhere
 2. Installed our application in it
-3. Put _just_ that application somwehere on our PATH
+3. Put _just_ that application somewhere on our PATH
 
 Since we never need to import it, we can get away without activation. This is exactly what `pipx` (pip for executables) and `uv tool` do!
 
@@ -398,7 +398,7 @@ dev = [] # 4
 :::{glossary}
 build-system.requires
 : Requirements that are installed when building distributions. This is your
-build-backend, and anything else require to assemble your package from source.
+build-backend, and anything else required to assemble your package from source.
 These are not available at runtime for users. Noted with `# 1` above.
 
 project.dependencies
@@ -408,7 +408,7 @@ of your package will also install these. Noted with `# 2` above.
 project.optional-dependencies
 : This is a table with arbitrary keys. When a user is installing your package,
 they can add `[extra]` to install the list of dependencies named `extra`.
-These will not neccisarly be present if the user didn't request then. Also
+These will not necessarily be present if the user didn't request them. Also
 known as "extras". These are part of the public package metadata. Noted with
 `# 3` above.
 

content/basic-packaging/04_sp_guide.md

@@ -172,7 +172,7 @@ repos:
     rev: "v0.15.18"
     hooks:
       - id: ruff-check
-        args: ["--fix",]
+        args: ["--fix"]
       - id: ruff-format
 ```
 
@@ -330,7 +330,7 @@ The guide keeps going well past this tour. Skim these when the need arises:
 ## Using the cookiecutter
 
 Rather than assembling all of this by hand, [cookie][] generates a new package
-that already follows the guide. It supports **eleven** build backends,
+that already follows the guide. It supports **ten** build backends,
 including the compiled ones (`pybind11`, `scikit-build-core`, `maturin`, …)
 you'll use later in this workshop.
 

content/compiled/01_compiled.md

@@ -399,7 +399,7 @@ If you need files from somewhere else, you can use `sdist.force-include`
 :::{note}
 
 * Do your tests go in the SDist? Yes.
-* Do your docs go in the SDist? Ehh. Depends. Kindof.
+* Do your docs go in the SDist? Ehh. Depends. Kind of.
 * Do your CI files go in the SDist? No, but who cares, they are small.
 :::
 

content/compiled/04_cibuildwheel.md

@@ -4,7 +4,7 @@
 
 In the [basic publishing chapter](../basic-packaging/05_publishing_ci.md), one
 job built an SDist and a wheel, and one job uploaded them. If you have
-compiled components, you need slightly more than one wheel::
+compiled components, you need slightly more than one wheel:
 
 $$ 3 \text{ OSs} \times 2 \text{ architectures} \times 5 \text{ CPython versions} = 30 \text{ wheels} $$
 
@@ -55,8 +55,8 @@ build-frontend = "build[uv]"
 
 Other options you'll reach for eventually: `skip` (e.g. `"*musllinux*"` to drop
 musl wheels), and `environment` (set environment variables like compiler flags
-inside the build, linux runs in a container so doesn't see the host's
-environment). See the [options docs][cibw options].
+inside the build; Linux builds run in a container, so they don't see the
+host's environment). See the [options docs][cibw options].
 
 ## Try it locally
 
@@ -244,8 +244,8 @@ fallback) is exactly as described in
 Give your compiled package a `.github/workflows/cd.yml` using the pieces
 above, and add the `[tool.cibuildwheel]` configuration to its
 `pyproject.toml`. If you have it on GitHub, push it to a branch and trigger
-the workflow with the "Run workflow" button (`workflow_dispatch` runs build
-everything but skip the upload); then download the wheels from the run's
+the workflow with the "Run workflow" button (`workflow_dispatch` builds
+everything but skips the upload); then download the wheels from the run's
 artifacts.
 
 :::

content/other-tools/01_plugin.md

@@ -13,7 +13,7 @@ project, or if a project is mostly Python, or if you need to combine plugins
 The plugins reuse the same CMake machinery and the same `[tool.scikit-build]`
 configuration as the standalone backend, so most of what you learned in the
 [scikit-build chapters](../scikit-build/01_custom.md) carries over. The
-difference is who _owns_ the build: the host backend runs the wheel and SDist,
+difference is who _owns_ the build: the host backend builds the wheel and SDist,
 and scikit-build-core contributes the compiled bits as a hook.
 
 ## Hatchling

content/other-tools/03_conda_forge.md

@@ -274,23 +274,23 @@ To get a conda recipe on conda-forge you need to submit it for build checks and
 
    and then open a **draft** pull request against the `upstream`'s `main` branch.
 
-   Ensure that you read and follow and complete the checklist.
+   Ensure that you read, follow, and complete the checklist.
    Once your builds are passing, mark your PR as ready for review and tag the relevant [conda-forge/staged-recipes review team](https://github.com/conda-forge/staged-recipes#review-teams).
    For pure-Python packages this would be
 
    ```text
    @conda-forge/help-python, ready for review!
    ```
 
-   and for packages with compile extensions this would be
+   and for packages with compiled extensions this would be
 
    ```text
    @conda-forge/help-python-c, ready for review!
    ```
 
    Once you do so, the conda-forge-webservices will apply the relevant tags for the review team to find the recipe.
 
-7. Once your recipe is reviewed and approved, it will be merged, which will then kick of automation to generate a conda-forge feedstock at `https://github.com/conda-forge/<package name>-feedstock` and to generate a maintainer team on GitHub populated by the `extra.recipe-maintainers` list in the package recipe.
+7. Once your recipe is reviewed and approved, it will be merged, which will then kick off automation to generate a conda-forge feedstock at `https://github.com/conda-forge/<package name>-feedstock` and to generate a maintainer team on GitHub populated by the `extra.recipe-maintainers` list in the package recipe.
    Your package feedstock will be automatically regenerated by the `conda-forge-admin` bot account and then the built packages will be automatically uploaded to <https://anaconda.org/channels/conda-forge>.
 
 ## Getting help

content/other-tools/04_distros.md

@@ -24,7 +24,7 @@ You do not have to be a packager to help with distro packaging.
 Just running the downstream package build in upstream is a huge step towards it.
 If your project is not yet packaged, that's fine, you can do it yourself.
 
-The only files you need to manage is a `.spec` file and enable `packit` configuration[^2].
+The only files you need to manage are a `.spec` file and a `packit` configuration[^2].
 The spec file can be quite minimal and low/no maintenance:
 
 ```rpmspec
@@ -64,8 +64,8 @@ Lorem ipsum
 %autochangelog
 ```
 
-Packit is a service available as a GitHub app and GitLab, but can be extended upon request.
-There are some [onboarding steps] to follow, after which you get distro builds in upstream project.
+Packit is a service available as a GitHub app and on GitLab, but can be extended upon request.
+There are some [onboarding steps] to follow, after which you get distro builds in your upstream project.
 
 ```{image} 04_distros-packit_example.png
 :alt: Packit jobs run in upstream
@@ -81,7 +81,7 @@ There are a bunch of edge-case issues you should not be subjected to.
 :alt: Packaging is dangerous business
 ```
 
-Doing the whole packaging process is a daunting process.
+Doing the whole packaging process yourself is daunting.
 It is best to contact your local neighborhood distro packager.
 You can find some in [#scitech] or [#python] channels in Fedora matrix who also share your interest.
 [#devel] channel is where you find everyone else if you're feeling social.

content/scikit-build/03_dynamic_metadata.md

@@ -40,7 +40,7 @@ sdist.include = ["src/package/_version.py"]
 provider = "scikit_build_core.metadata.setuptools_scm"
 
 [tool.setuptools_scm]  # Section required
-write_to = "src/package/_version.py"
+version_file = "src/package/_version.py"
 ```
 
 :::
@@ -59,7 +59,7 @@ sdist.include = ["src/package/_version.py"]
 metadata.version.provider = "scikit_build_core.metadata.setuptools_scm"
 
 [tool.setuptools_scm]  # Section required
-write_to = "src/package/_version.py"
+version_file = "src/package/_version.py"
 ```
 
 :::
@@ -73,7 +73,7 @@ write_to = "src/package/_version.py"
 - Configure all other (arbitrary) keys that the provider consumes in `tool.dynamic-metadata` or other `tool.*`
 - Profit?
 
-[^1]: With PEP808 you can have mixed static and dynamic fields for table and array fields like `dependencies`, `scripts`
+[^1]: With PEP 808 you can have mixed static and dynamic fields for table and array fields like `dependencies`, `scripts`
 
 ## Pre-defined plugins
 
@@ -264,7 +264,7 @@ path = "README.md"
 - inputs:
   - `text`: A literal text
   - `path`: A file to read
-  - `content-type`: The readme content (default: `text/markdown`)
+  - `content-type`: The readme content type (default: `text/markdown`)
   - `start-after`, `end-before`: Markers indicating the content (exclusive)
   - `start-at`, `end-at`: Markers indicating the content (inclusive)
   - `pattern`: A regex pattern to capture the fragment

content/scikit-build/04_editable_installs.md

@@ -31,11 +31,11 @@ Effectively builds the CMake project with source-dir (`-S`) the same as build-di
 
 :::{warning}
 This mode requires _you_ to setup the CMake build to put the build artifacts in the correct place relative to the source.
-::::
+:::
 
 ## Scikit-build-core 1.0 tricks and tips
 
-Use can now rebuild the CMake project on demand with
+You can now rebuild the CMake project on demand with
 
 ```{code} python
 :linenos:
@@ -59,8 +59,8 @@ uv sync --no-build-isolation
 
 ### Use `importlib.resources`
 
-Inherently `redirect` editable mode behaves like a namespaced package, i.e. sources are in multiple locations.
-You cannot rely on patterns like `__file__` to navigate to
+Inherently `redirect` editable mode behaves like a namespace package, i.e. sources are in multiple locations.
+You cannot rely on patterns like `__file__` to navigate to files in your package.
 
 ```{code} python
 >>> from pathlib import Path

content/scikit-build/05_overrides.md

@@ -54,7 +54,7 @@ The current `if.*` conditionals available are:
 - `wheel.cmake` (bool): if there are known CMake wheels available for the system
 - `failed` (bool): whether a build has failed, used to try again with other options
 
-where the `regex`, `version`, `bool` conditionals check if the variable match the provided regex pattern,
+where the `regex`, `version`, `bool` conditionals check if the variable matches the provided regex pattern,
 version specifier, boolean state respectively.
 
 Then you provide any variables you would provide for `tool.scikit-build` to override.
@@ -77,7 +77,7 @@ cmake.define.BUILD_MPI = true
 cmake.define.MPI_PROC = "2"
 ```
 
-If environment variable `WITH_MPI` is not defined is equivalent to
+If environment variable `WITH_MPI` is not defined, it is equivalent to
 
 ```toml
 [tool.scikit-build]
@@ -87,7 +87,7 @@ cmake.define.BUILD_TESTS = false
 
 :::
 
-:::{tab-item} no inheirt
+:::{tab-item} no inherit
 
 ```toml
 [tool.scikit-build]

slides/0_01_intro.md

@@ -20,7 +20,7 @@ Some logistics:
 
 - Everyone should have gotten a badge
 - We'll be sharing catering with SciPy tutorials
-- We have enough left over funds for a workshop dinner (need to find a place!)
+- We have enough leftover funds for a workshop dinner (need to find a place!)
 
 
 ---
@@ -34,7 +34,7 @@ Some logistics:
 It's hard to target everyone! So let's try a few things:
 
 - Focus on interactivity - questions and talking is good (workshop)
-- Will have a mix of overviews and indepth dives
+- Will have a mix of overviews and in-depth dives
 - Everyone might see some new stuff!
 - Groups can break out to work on stuff if you want
 

slides/1_04_sp_guide.md

@@ -279,7 +279,7 @@ The guide keeps going well past this tour:
 ## Using cookie
 
 Rather than assembling all this by hand, **cookie** generates a new package that
-already follows the guide — **eleven** build backends, including the compiled
+already follows the guide — **ten** build backends, including the compiled
 ones (`pybind11`, `scikit-build-core`, `maturin`, …).
 
 <div class="columns">

slides/4_04_editable_installs.md

@@ -102,9 +102,9 @@ Off to the races!
 
 - If you think you need it
   - Do you really need it?
-- If you sure you need it
+- If you're sure you need it
   - Have you exhausted all options?
-- `inplace` is really what you want
+- If `inplace` is really what you want
   - Why?
 
 ---
@@ -115,7 +115,7 @@ Off to the races!
   - `CMakeCache.txt` etc.
   - We cannot help you delete build files
 - You have to put build artifacts in correct place
-- Since 1.0: try `edtiable.rebuild-dir` instead
+- Since 1.0: try `editable.rebuild-dir` instead
 
 ---
 
@@ -160,7 +160,7 @@ NotADirectoryError: [Errno 20] Not a directory: 'test.py/../my_lib.so'
 ## 1.0 changes
 
 - `<pkg>.__loader__.rebuild()`: rebuild on demand
-- `edtiable.rebuild-dir`: specify where to install
+- `editable.rebuild-dir`: specify where to install
 - `importlib.resources` should work properly (custom implementation)
 
 ---

slides/5_04_distros.md

@@ -16,12 +16,12 @@ _class: lead
 
 - What about `conda`, `spack`, etc.?
   - Does not have extensive testing, vulnerability tracking, etc.
-- Are traditional packaging dying?
+- Is traditional packaging dying?
   - Not for non-gui apps/libraries
   - Still valuable even if you have a flatpak app
 - Isn't it a big commitment?
   - Not for you, that's the packager's job
-  - Your only job is be open and communicate
+  - Your only job is to be open and communicate
 
 ---
 
@@ -36,7 +36,7 @@ _class: lead
 
 All you need is
 - `.spec` file: how to build the package
-- `packit` app: does the build shows the result
+- `packit` app: does the build, shows the result
 
 ---