Are your Python build requirements pinned? Build isolation explained

Usually not. When pip builds a source distribution, it installs the build requirements from pyproject.toml into a temporary isolated environment. Your runtime requirements file and its constraints do not automatically apply there. Pip has a separate build-constraint option for that gap, and wheel only installs avoid the issue entirely.

What build isolation is

The pip build system interface guide explains it. For building packages, pip uses an isolated environment: build time Python dependencies are installed in a temporary directory added to the path for the build commands. This keeps build requirements independent of your runtime environment. A project that needs an older setuptools can still be built even if you have a newer one installed.

The requirements come from the build-system section of pyproject.toml, in a list called requires. They can be ranges, for example a compatible release of setuptools, and the guide notes they follow the standard requirement specifier format, so they can even reference URLs. Backends can also add dynamic build requirements through a hook.

Why this is a supply chain gap

Consider a typical project. Your requirements file pins every runtime package to an exact version. But a dependency that ships only as a source distribution needs setuptools, a compiler wrapper or a Cython version to build, and those come from its pyproject.toml, usually as ranges. Each install can fetch the latest allowed release of those tools and run them.

The PEP 708 text points at the same weakness in a different context. In discussing why relying on hash checking alone is incomplete, it says protection is difficult and verbose when dependencies are not provided through a requirements file, and it names build time dependencies as affected.

What to do

Pip's install and lock commands both list the build-constraint option, described as constraining build dependencies using the given constraints file. It can be given more than once, and has the environment variable PIP_BUILD_CONSTRAINT. It is separate from the ordinary constraint option, which applies to what you install.

python -m pip install -r requirements.txt -c constraints.txt --build-constraint build-constraints.txt

Whether hash checking extends to build requirements is not something this article can confirm from the documentation reviewed, so test your own setup and treat any gap as open until you have seen it fail closed.

Disabling isolation is not a shortcut

The no-build-isolation flag makes pip stop managing build time dependencies. The guide says the person supplying it is responsible for ensuring the build environment is managed appropriately, including that all required build time dependencies are installed. It is valid for controlled builds, but it moves the pinning problem to you.

A practical sequence

1. List which dependencies in your lock or requirements file ship only as sdists.
2. For each, decide: find a wheel, build a wheel once and keep it, or write a build constraints file.
3. Prefer the first. Fewer builds means fewer places for code to run.

See pip install: wheel or source, what runs on your machine.

Safeguard's dependency scanning and SBOM generation list the packages your project resolves, which helps you find the sdist only ones to review. A free scan is available at gold.safeguard.sh/scan.

Quick check

Sources

• pip documentation, Build System Interface
• pip documentation, pip install reference
• pip documentation, pip lock
• PEP 708

Last reviewed: 19 October 2026.