You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 793edd4
Browse filesBrowse the repository at this point in the historyBrowse files
Fix requirements files read as absent when not UTF-8 (#1120, #1119) (#1152)
* Start fix for #1120, #1119
Assisted-by: Claude Code:claude-opus-5-5
* Read requirements files the way pip decodes them
A requirements.txt that pip or uv installs from was read as absent
whenever it was not plain UTF-8:
- A file saved as Latin-1 or cp1252 with a PEP 263 coding line
("# -*- coding: latin-1 -*-") was skipped by lock-only discovery, so
a fresh-checkout scan said "No pypi packages found" and exited 0
while pip installed the unpatched release (#1119).
- A UTF-16 requirements.txt exported beside uv.lock (what
`uv export > requirements.txt` writes in Windows PowerShell 5.1) was
ignored by the vendored routing, `vendor --check` and `vex`. The scan
gave no pypi_multiple_lockfiles warning, the check passed and VEX
attested not_affected while `uv pip install -r requirements.txt`
installed the unpatched release (#1120).
pip's decoder now lives in one place. utils::requirements::decode
follows pip's auto_decode: byte-order marks first, then a PEP 263
coding line in the first two lines (UTF-8, ASCII, Latin-1 and cp1252
and their Python aliases), then UTF-8. A codec it does not model is
reported as unreadable, never guessed.
Every reader that only observes requirements files now goes through
it: the -r include walk, the vendored #612 probe beside a tool lock,
and VEX discovery. The probe also counts a requirements.txt it cannot
decode as one that may pin the package, so the warning fails closed.
The vendored planner still refuses files that are not UTF-8, since it
rewrites them byte for byte.
Fixes#1119Fixes#1120
Assisted-by: Claude Code:claude-opus-5-5
* Test vendor --check on a UTF-16 export beside uv
Adds the CLI-level regression for #1120: a requirements.txt exported
beside uv.lock (UTF-8, UTF-16 LE and UTF-16 BE) makes `vendor` warn
pypi_multiple_lockfiles and `vendor --check` fail on the contested
wiring, and is left byte-for-byte as the user wrote it. Before the
decoder change, both UTF-16 cases passed the check as if the file were
absent.
Refs #1120
Assisted-by: Claude Code:claude-opus-5-5
* Use the shared BOM helper in the requirements decoder
The formats::text guard test requires every UTF-8 BOM check to go
through the shared helpers (#905). The PEP 263 step checked for the
mark inline; it now asks strip_bom_bytes instead. No behavior change.
Refs #1119
Assisted-by: Claude Code:claude-opus-5-5
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments