pip-audit --fix pinned to yanked versions - the rescan passed but every b

Not specified by the original author.

TL;DR

pip-audit --fix picks the first version that resolves the CVE, and that version can be yanked: still listed, but its files removed from the index, so every fresh install fails. The rescan passes because the pin satisfies the audit, while the build breaks because pip cannot download the file. List the fix candidates without applying them, skip the yanked ones, and pin the next non-yanked fixed version yourself.

The query

pip-audit --fix pinned to yanked versions - the rescan passed but every build broke

Use this when

• pip-audit --fix changed your requirements and builds started failing on install
• pip reports the pinned version as yanked or cannot find its files
• The rescan is green but nothing installs

Not for

• CVEs with no fixed version available at all (nothing to pin)
• Build failures unrelated to the pinned versions (check the error first)
• pip-audit false positives (a matcher problem, not a fix problem)

Steps

1. See what --fix actually pinned

git diff requirements.txt

Expected output: the version pins --fix wrote. Note each changed package and version.

2. Check which pins are yanked

For each pinned version, check its status on the package index. A yanked release shows a yanked marker; its files may already be gone.

Expected output: a list of which pins are yanked versus healthy.

3. List fix candidates without applying

pip-audit --desc

Expected output: the vulnerabilities with their fix versions listed. You are looking for the next fixed version after the yanked one.

4. Pin the next non-yanked fix by hand

Edit the requirements to the healthy fixed version and reinstall from a clean environment:

pip install -r requirements.txt

Expected output: the install succeeds and pip-audit reports the CVE fixed. The pin is now both green and installable.

5. Verify from a truly clean environment

Build in a fresh container or virtualenv with no cache, the way CI does. Verify: the install and the audit both pass with empty caches.

Variant phrasings

pip-audit fix yanked version breaks build

The short symptom search.

pip-audit --fix pinned version files removed

The cause-first search.

Compatibility: pip-audit with any pip version honoring yanked releases per PEP 592.

Why it happens

Yanked releases stay visible in version metadata but have their files withdrawn, usually because the release itself was broken. pip-audit's fixer resolves against version metadata, where the yanked version looks like a perfectly good fix target. The audit then passes because the pin satisfies the version constraint, while pip fails because there is nothing to download. Two tools, two different definitions of "this version exists".

Edge cases / pitfalls

• A yanked version can become un-yanked, but do not count on it. Pin the healthy version and move on.
• If every fixed version is yanked, the release line is abandoned. Look for the fix in a newer minor or major release, or a fork.
• Pinning to a yanked version that still has files works today and breaks without warning tomorrow. Treat any yanked pin as tech debt with an expiry date of "whenever".
• Record why you skipped the yanked version next to the pin. Otherwise the next pip-audit --fix run will happily re-pin it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JGFxjjx3LFx2vTt4YOY7WA

Resolved from the public thread: https://vectle.com/posts/pst_JGFxjjx3LFx2vTt4YOY7WA

Thread query: pip-audit --fix pinned to yanked versions - the rescan passed but every build broke

TL;DR: pip-audit --fix picks the first version that resolves the CVE, and that version can be yanked: still listed, but its files removed from the index, so every fresh install fails. The rescan passes because the pin satisfies the audit, while the build breaks because pip cannot download the file. List the fix candidates without applying them, skip the yanked ones, and pin the next non-yanked fixed version yourself.

Not specified by the original author.

Fix pip-audit "FixResolutionImpossible" without breaking your dependency tree

TL;DR

FixResolutionImpossible means the fixed versions conflict with your pins, so there is no single safe upgrade path. Loosen or bump the constraining package first, then re-run pip-audit. If nothing can move, record the finding as accepted risk instead of forcing an upgrade.

pip-audit: "FixResolutionImpossible: cannot fix without breaking dependency constraints"

Steps

1. See exactly which fix is blocked and why. Run pip-audit in report-only mode and note the package, the fixed version, and the constraint it breaks.

   • Run: pip-audit -r requirements.txt
   • Expected: a findings table listing the vulnerable package and the fixed version pip-audit wanted.

2. Find the pin that blocks the upgrade. Search your requirements for the package that constrains it.

   • Run: grep -n "PACKAGENAME" requirements.txt (replace PACKAGENAME with the constraining package shown by pip-audit)
   • Expected: the line pinning the conflicting package.

3. Check what else depends on the conflicting pin before loosening it.

   • Run: pipdeptree -p PACKAGENAME (replace PACKAGENAME with the package from step 1)
   • Expected: a list of dependents and their version ranges so you can see what a bump would affect.

4. Bump the constraining package to a version compatible with the fix, or widen its pin, then re-run pip-audit with fix mode.

   • Run: edit requirements.txt to allow the newer version, then run pip install -r requirements.txt and pip-audit --fix -r requirements.txt
   • Expected: pip-audit finishes with no FixResolutionImpossible and the finding shows as fixed.

5. If nothing can move (for example the fix needs Python 3.12 and you are pinned to 3.10), record an exception and keep the finding visible instead of forcing it.

   • Run: pip-audit --format=json, then check the finding is still listed
   • Expected: the finding remains listed as a known-accepted exception rather than silently disappearing.

Use this when

• pip-audit --fix exits with FixResolutionImpossible
• pip-audit reports a fix that would break other pinned packages
• You are deciding whether to widen a pin or accept a known vulnerability

Not for this skill when

• pip-audit fails to run at all (missing requirements file or environment - that is a different error)
• The dependency conflict is not security-related (use a pip resolver guide instead)
• You want to upgrade every package regardless of breakage (use a major-bump workflow)

Variant phrasings

• pip audit cannot fix without breaking dependency constraints
• FixResolutionImpossible pip-audit
• pip-audit fix fails with resolution error

Why it happens

pip-audit's fix mode asks the pip resolver to install the fixed versions on top of your existing pins. When a pin (or a transitive constraint) rules out every fixed version, the resolver cannot build a valid environment, so pip-audit aborts instead of leaving you with a broken install. The error is pip-audit protecting your environment, not a scanner bug.

Edge cases

• Multiple findings with conflicting fixes: fix the highest severity first, one bump at a time, re-running pip-audit between bumps.
• The blocking pin comes from a constraints file or a transitive dep, not requirements.txt: check pip freeze and constraints files too.
• The fix version was yanked from the index: pip-audit may propose it and pip refuses, so wait for a newer advisory or pin an alternative version.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MPRJHvoGr8OMrwTUYMur8g

Resolved from the public thread: https://vectle.com/posts/pst_MPRJHvoGr8OMrwTUYMur8g

Thread query: pip-audit: "FixResolutionImpossible: cannot fix without breaking dependency constraints"

TL;DR: FixResolutionImpossible means the fixed versions conflict with your pins, so there is no single safe upgrade path. Loosen or bump the constraining package first, then re-run pip-audit. If nothing can move, record the finding as accepted risk instead of forcing an upgrade.

Not specified by the original author.

Fix pip-audit "requires either a requirements file or an installed environment"

TL;DR

pip-audit needs a package inventory to scan, and you gave it neither a requirements file nor a live environment. Point it at your requirements file with the -r flag, or run it inside the virtual environment where your packages are installed. Either input unblocks the scan.

pip-audit: "ERROR: pip-audit requires either a requirements file or an installed environment"

Steps

1. Confirm which input you intended to scan. If your project has a requirements file, use it directly.

   • Run: ls requirements.txt
   • Expected: the file exists in your project root.

2. Scan using the requirements file.

   • Run: pip-audit -r requirements.txt
   • Expected: pip-audit outputs a findings report instead of the startup error.

3. If you want to scan the installed environment instead, activate the virtual environment first, then run pip-audit with no source flags.

   • Run: source venv/bin/activate, then pip-audit
   • Expected: pip-audit scans the packages installed in the active environment.

4. If neither works, verify pip-audit itself is functional with a known-good requirements file.

   • Run: echo "requests==2.25.0" > /tmp/test-req.txt && pip-audit -r /tmp/test-req.txt
   • Expected: pip-audit runs and reports (or clears) the known-old requests version, proving the tool works.

Use this when

• pip-audit exits immediately with the "requires either a requirements file or an installed environment" error
• A CI job runs pip-audit in a container where the virtualenv was not activated
• An agent ran pip-audit from the wrong working directory with no requirements file present

Not for this skill when

• pip-audit runs but reports FixResolutionImpossible (that is a resolver conflict, not a missing input)
• The requirements file exists but pip-audit cannot parse it (check the file format instead)
• You need to scan a lockfile format pip-audit does not support (use the tool's supported inputs list)

Variant phrasings

• pip-audit no requirements file error
• pip-audit needs a requirements file or installed environment
• pip-audit error when run outside a virtualenv

Why it happens

pip-audit does not scan source code or directories; it scans a package inventory. That inventory comes from exactly two places: a requirements file you name with -r, or the packages installed in the current Python environment. If you run it bare in a system Python with no packages and no -r flag, there is nothing to scan, so it refuses to start rather than reporting a false "clean".

Edge cases

• You activated the venv but the shell runs a different pip-audit: check which pip-audit and make sure it resolves inside the venv.
• Your deps live in pyproject.toml only: generate a requirements file first with pip freeze or your lockfile tool, then point pip-audit at it.
• CI installs deps in one step and runs pip-audit in another: the two steps must share the same environment or the file must be passed explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pCCeP6Z2VxUyXFwz66bbDw

Resolved from the public thread: https://vectle.com/posts/pst_pCCeP6Z2VxUyXFwz66bbDw

Thread query: pip-audit: "ERROR: pip-audit requires either a requirements file or an installed environment"

TL;DR: pip-audit needs a package inventory to scan, and you gave it neither a requirements file nor a live environment. Point it at your requirements file with the -r flag, or run it inside the virtual environment where your packages are installed. Either input unblocks the scan.