Have you ever shipped broken SDists with missing files or possibly dirty SDists with files that shouldn't have been there? Have you noticed that standards compliant tools aren't making the same SDist that flit build is? Is hatchling adding .DSStore files when you ship from your macOS? No matter what build-backend you use, check-sdist can help!

Check-sdist builds an SDist and compares the contents with your Git repository contents. It can even temporarily inject common junk files (like pycache files or OS specific files) and help verify that those aren't getting bundled into your SDist. If you are getting files you didn't expect or missing files you did expect, consult your build backend's docs to see how to include or exclude files.

To run with pipx:

$ pipx run check-sdist[uv]

Or, if you like uv instead (faster):

$ uvx check-sdist

You can add --no-isolation to disable build isolation (faster, but must preinstall build dependencies), --source-dir to select a different source directory to check, and --inject-junk to temporarily inject some common junk files while running. You can select an installer for build to use with --installer=, choices are uv, pip, or uv|pip, which will use uv if available (the default).

If you need the latest development version:

$ pipx run --spec git+https://github.com/henryiii/check-sdist check-sdist
$ uvx --from git+https://github.com/henryiii/check-sdist check-sdist

To use the pre-commit integration, put this in your .pre-commit-config.yaml:

- repo: https://github.com/henryiii/check-sdist
  rev: v1.3.1
  hooks:
    - id: check-sdist
      args: [--inject-junk]
      additional_dependencies: [] # list your build deps here

This requires your build dependencies, but in doing so, it can cache the environment, making it quite fast. The installation is handled by pre-commit; see pre-commit-uv if you want to try to optimize the initial setup. You can also use prek, which is a Rust pre-commit compatible runner that uses uv. If uv is present (including in your additional_dependencies), the build will be slightly faster, as uv is used to do the build. If you don't mind slower runs and don't want to require a build dependency listing:

- repo: https://github.com/henryiii/check-sdist
  rev: v1.3.1
  hooks:
    - id: check-sdist-isolated
      args: [--inject-junk]

This one defaults to including uv in additional_dependencies; you shouldn't have to specify anything else.

To configure, these options are supported in your pyproject.toml file:

[tool.check-sdist]
sdist-only = []
git-only = []
default-ignore = true
recurse-submodules = true
mode = "git"
build-backend = "auto"

You can add .gitignore style lines here, and you can turn off the default ignore list, which adds some default git-only files.

By default, check-sdist recursively scans the contents of Git submodules, but you can disable this behavior (e.g. to support older Git versions that don't have this capability).

You can also select mode = "all", which will instead check every file on your system. Be prepared to ignore lots of things manually, like *.pyc files, if you use this.

You can tell check-sdist to look for exclude lists for a specific build backend with build-backend, or "none" to only use it's own exclude list. Build backends supported are "flit_core.buildapi", "hatchling.build", "scikit_build_core.build", "pdm.backend", "maturin", and "poetry.core.masonry.api". The default, "auto", will try to detect the build backend if build-system.build-backend is set to a known value.

check-sdist will ignore *.dist-info in SDists, since those are generated. If the build backend is clearly setuptools, it will also ignore *.egg-info, as setuptools generates this. If you've wrapped your build backend, you'll need to add this to the sdist-only ignore list manually.

• check-manifest: A (currently) setuptools specific checker that can suggest possible ways to include/exclude files.
• Scientific Python Development Guide: Guidelines on which this package was designed.