diff --git a/content/basic-packaging/01_setup.md b/content/basic-packaging/01_setup.md index c896a7e..6494752 100644 --- a/content/basic-packaging/01_setup.md +++ b/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. diff --git a/content/basic-packaging/04_sp_guide.md b/content/basic-packaging/04_sp_guide.md index 8f30238..363aa3c 100644 --- a/content/basic-packaging/04_sp_guide.md +++ b/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. diff --git a/content/compiled/01_compiled.md b/content/compiled/01_compiled.md index 6860a8c..634d1db 100644 --- a/content/compiled/01_compiled.md +++ b/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. ::: diff --git a/content/compiled/04_cibuildwheel.md b/content/compiled/04_cibuildwheel.md index e1144cb..550e5da 100644 --- a/content/compiled/04_cibuildwheel.md +++ b/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. ::: diff --git a/content/other-tools/01_plugin.md b/content/other-tools/01_plugin.md index b9bb710..57bf400 100644 --- a/content/other-tools/01_plugin.md +++ b/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 diff --git a/content/other-tools/03_conda_forge.md b/content/other-tools/03_conda_forge.md index cf1f390..b09dc56 100644 --- a/content/other-tools/03_conda_forge.md +++ b/content/other-tools/03_conda_forge.md @@ -274,7 +274,7 @@ 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 @@ -282,7 +282,7 @@ To get a conda recipe on conda-forge you need to submit it for build checks and @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! @@ -290,7 +290,7 @@ To get a conda recipe on conda-forge you need to submit it for build checks and 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/-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/-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 . ## Getting help diff --git a/content/other-tools/04_distros.md b/content/other-tools/04_distros.md index 5716925..8cef613 100644 --- a/content/other-tools/04_distros.md +++ b/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. diff --git a/content/scikit-build/03_dynamic_metadata.md b/content/scikit-build/03_dynamic_metadata.md index 25555ea..04c3ce2 100644 --- a/content/scikit-build/03_dynamic_metadata.md +++ b/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 diff --git a/content/scikit-build/04_editable_installs.md b/content/scikit-build/04_editable_installs.md index 0db29cc..a85b820 100644 --- a/content/scikit-build/04_editable_installs.md +++ b/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 diff --git a/content/scikit-build/05_overrides.md b/content/scikit-build/05_overrides.md index 7f2dc95..b3f5b71 100644 --- a/content/scikit-build/05_overrides.md +++ b/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] diff --git a/slides/0_01_intro.md b/slides/0_01_intro.md index 945d0a6..d03c6dd 100644 --- a/slides/0_01_intro.md +++ b/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 diff --git a/slides/1_04_sp_guide.md b/slides/1_04_sp_guide.md index ee413b1..0516abf 100644 --- a/slides/1_04_sp_guide.md +++ b/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`, …).
diff --git a/slides/4_04_editable_installs.md b/slides/4_04_editable_installs.md index 7ac48b5..1ea621e 100644 --- a/slides/4_04_editable_installs.md +++ b/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 - `.__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) --- diff --git a/slides/5_04_distros.md b/slides/5_04_distros.md index af71026..2177c6e 100644 --- a/slides/5_04_distros.md +++ b/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 ---