Does pip's only-binary option make installs safer, and what breaks?

The only-binary option tells pip not to use source packages, so any package without a wheel fails to install. It narrows what runs on your machine during install, but it does not make a wheel trustworthy. Use it in CI as a tripwire and accept that some packages will need an exception.

What the option does

The pip reference defines the two format options plainly. No-binary says do not download binary packages. Only-binary says do not use source packages, and adds that packages without binary distributions fail to install. Both accept the special values all and none, or a comma separated list of package names, and each use adds to the set.

A softer cousin, prefer-binary, prefers wheels even when a source package is newer, but still allows source builds.

pip install --only-binary :all: -r requirements.txt

Why it matters for security

When pip installs from a source distribution, it uses the project's build backend to produce metadata and a wheel. The pip page does not spell out the security implications, but it does describe that build step and the fact that build dependencies named by PEP 518 are involved. A source install therefore means build tooling from the package runs on your machine. A wheel is already built, so installing it does not need that step.

That is a smaller attack surface at install time. It is not a verdict on the code inside, because the wheel's code runs when you import it. Read pip install: wheel or source, what runs on your machine for the full picture.

What breaks

• Packages that publish only a source distribution.
• Platforms where no matching wheel exists, for example an unusual CPU or an old Python version.
• Packages whose own build dependencies are needed at install time.

The pip docs warn that the opposite choice, no-binary, can fail on packages that are tricky to compile. Either strictness has a cost, so use it where you can afford the failures.

A rollout for a solo project

1. Run the install once with only-binary on all packages in a throwaway environment.
2. List the failures. Each one is a package that builds from source on your machine today.
3. Decide per package: pin a version that has a wheel, replace it, or allow it by name with a no-binary exception for that package only.
4. Add the strict command to CI so a new source-only dependency shows up as a failed build, not a silent change.
5. Combine with hash checking so the file you tested is the file you install. See how pip hash checking mode works.

The build isolation option

Pip also has a no-build-isolation option. The docs say it disables isolation when building a modern source distribution, and that PEP 518 build dependencies must already be installed if you use it. Most projects should leave isolation on, since it keeps builds from depending on whatever happens to be in the environment.

Try it yourself

Click through it at your own pace, or open it full screen. Find where each dependency comes from, which is the first step before deciding which ones may build from source.

Quick check

Sources

• pip documentation: pip install

Last reviewed: 19 October 2026.