---
id: pep517
version: "0.13.1"
license: unclear
license_treatment: permissive
maintenance: active
---

# pep517 — Wrappers to build Python packages using PEP 517 hooks

License: permissive · Maintenance: active · Downloads: 9.4M/mo

## What it is and what it does

pep517 is a low-level wrapper around the PEP 517 and PEP 660 build system specifications for Python packages. It lets you call build backend hooks (like build_wheel, build_sdist) in an isolated subprocess, with fallbacks for optional hooks so you don't have to check which ones are defined. The package handles the mechanics of invoking a package's build backend without running it in your current process.

The package is now deprecated in favor of pyproject-hooks (lower level) and build (higher level), but remains actively maintained. It depends on tomli for reading pyproject.toml, plus importlib_metadata and zipp for compatibility. You are responsible for installing the build requirements specified in pyproject.toml before calling the hooks.

Use it for:

- Build a Python wheel or sdist from a source directory with a PEP 517 backend, isolating the backend process.
- Query a build backend for its dynamic build requirements before installing them.
- Test whether a project's build backend is correctly configured using the command-line check tool.
- Implement a custom build frontend that needs to call multiple backends with subprocess isolation.

## Worth the install?

AI-flagged interpretation of the facts above — verify before relying.

Provides subprocess-isolated wrappers around PEP 517 and PEP 660 build hooks, letting you call Python package build backends without checking which hooks are implemented.

Yes, if you are building a build frontend or need subprocess isolation for PEP 517 backends. No, if you are packaging a single project—use the build package instead. The package is stable and well-maintained, but its deprecation status means new code should prefer pyproject-hooks or build unless you have a specific reason to use pep517 directly.

## Install

pip install pep517
uv add pep517
poetry add pep517

## Installing pep517

Before you install: Low friction: pure Python wheel with three lightweight runtime dependencies (tomli, importlib_metadata, zipp). Active maintenance as of April 2026, though the package itself is deprecated in favor of pyproject-hooks and build.

License in practice: MIT license (permissive): you can use this freely in commercial and private projects with minimal restrictions.

Quickstart:

import os
import tomli
from pep517.wrappers import Pep517HookCaller

src = 'path/to/source'
with open(os.path.join(src, 'pyproject.toml'), 'rb') as f:
    build_sys = tomli.load(f)['build-system']

hooks = Pep517HookCaller(
    src,
    build_backend=build_sys['build-backend'],
    backend_path=build_sys.get('backend-path'),
)
whl_filename = hooks.build_wheel('destination/folder', {})

You must manually ensure build requirements from pyproject.toml are installed in the environment before calling hooks.

Verify before relying:

- Whether the package's deprecation status affects long-term support or if it remains stable for existing users.
- Performance characteristics when calling hooks in subprocess isolation versus direct backend invocation.

## Package facts

- License: not declared (permissive)
- Python support: supports_current
- Install friction: low
- Maintenance: active
- Downloads: 9.4M/month (top 5,000 on PyPI)
- Known vulnerabilities: none known

## Tags

pep 517 build hooks, python package build backend, build system wrapper, pep 660 editable install, subprocess build isolation, python build frontend, build-system, pep-517, packaging

[View on SkillFed](https://skillfed.io/packages/pep517) · [View on PyPI](https://pypi.org/project/pep517/)