fix: hash verification in --dependency-constraints-txt could be silently skipped

[manfred-kaiser]

Problem

--dependency-constraints-txt reads the file with:

constraints=set(map(str.strip, dependency_constraints_file))

This treats every physical line as one independent constraint. It does not join
backslash-continued lines, so a file like the one pip-compile --generate-hashes
produces:

hatchling==1.31.0 \
    --hash=sha256:6b48ad...
    --hash=sha256:aac80b...

is split into three separate set elements: the requirement and each --hash line on
its own. When these get written back out to a temporary file for pip/uv
('\n'.join(constraints)), a set has no guaranteed iteration order, so the
requirement and its hashes may or may not end up adjacent again.

Impact

This is silent, not just cosmetic. When the continuation breaks apart, pip's
constraint parser reads the orphaned --hash line as unattached ("has --hash but
no requirement, and will be ignored") and installs the requirement without
checking any hash at all — no warning surfaces to the build output.

Verified directly against a single-dependency constraints file
(uv_build==0.12.0 --hash=sha256:...) with a deliberately wrong hash, same file,
same command, 8 runs back to back:

$ python -m build --dependency-constraints-txt requirements-build.txt -o dist .

run 1: build failed, wrong hash detected
run 2: build succeeded  ← wrong hash silently accepted
run 3: build succeeded  ← wrong hash silently accepted
run 4: build failed, wrong hash detected
run 5: build succeeded  ← wrong hash silently accepted
run 6: build succeeded  ← wrong hash silently accepted
run 7: build failed, wrong hash detected
run 8: build succeeded  ← wrong hash silently accepted

5 of 8 runs accept the tampered hash with no error and no indication in the output
that anything was skipped. With PYTHONHASHSEED fixed, the outcome becomes 100%
deterministic per seed (5/5 identical for a given seed) — different seeds give
different, opposite outcomes. This isolates the cause to set iteration order, not
to anything timing- or network-related.

• Against a larger, six-package constraints file (a hatchling build tree with
  multiple multi-hash entries), the failure was consistent rather than
  intermittent, but the symptom varied between runs: sometimes a hash got
  attributed to the wrong package, sometimes two unrelated requirement lines were
  concatenated into one invalid line (e.g. packaging==26.2 hatchling==1.31.0 pluggy==1.6.0).

So depending on the file and the hash seed, this flag can either crash with a
confusing parse error, or silently skip hash verification entirely while reporting
success.

Fix

Join continuation lines into complete logical lines before deduplicating, so every
set element is a self-contained, order-independent constraint (comments and blank
lines are also filtered out explicitly, matching how the file is meant to be read).

Test plan

• tests/test_main_helpers.py: three new tests —
  test_parse_constraints_txt_single_line,
  test_parse_constraints_txt_ignores_comments_and_blank_lines, and
  test_parse_constraints_txt_joins_backslash_continuations (the regression test,
  using a real pip-compile --generate-hashes-style fixture).
• Full existing suite (test_main.py, test_env.py, test_main_helpers.py) passes
  unchanged: 211 passed, 2 skipped (platform-specific).

[manfred-kaiser]

The two failing jobs (macOS pypy3.10/min, Windows 3.10/min) are unrelated to this change — both are transient network issues in test_integration.py building external packages: a RemoteDisconnected on macOS (Solaar) and a PyPI index serving an unexpected Content-Type on Windows (setuptools resolution). All jobs touching the changed code (test_main.py, test_main_helpers.py) passed. Happy to have a maintainer re-run them if needed — I don't have permission to trigger reruns on this repo myself.

[layday]

These aren't valid dependency specifiers, really - requirements.txt is its own minilang. We shouldn't be treating them the same way we do pyproject.toml dependencies or get_requires_for_*. I think the safest thing to do here is forward the constraints file to the installer as is. pip and uv are better equipped to parse it.

[manfred-kaiser]

Updated approach

Instead of re-parsing --dependency-constraints-txt into individual lines (which is what broke backslash-continued --hash options in the first place), this now reads the file once and passes its content through as a single, untouched unit — the installer backends' '\n'.join(constraints) then reproduces it byte-for-byte. No line splitting, no dedup, no reassembly, so the bug class is gone structurally rather than patched around. Net diff is smaller than the previous fix, and only touches _bootstrap_build_env.

On pip/uv and hash verification

Testing this end-to-end (real pip-compile --generate-hashes file, real package, correct vs. tampered hash) surfaced something worth flagging so it isn't mistaken for a regression here: whether a --hash sourced only from a -c constraints file (not repeated on the -r requirement) actually gets enforced depends on the installer version — both pip and uv have had the exact same class of resolver gap, just fixed at different times:

• uv < 0.4.6: didn't respect hashes from constraints files. Fixed in Respect hashes in constraints files astral-sh/uv#7093 (closing Respect SHAs in --constraints and --build-constraints files astral-sh/uv#7089), released 2024-09-05.
• pip < 26.1: same gap, opposite failure mode — a --hash in -c alone is never picked up, so pip aborts the build outright, correct or tampered hash alike (a hard failure, not a silent pass). Fixed in Allow unpinned requirements to use hashes from constraints pip#13887 (closing [regression] resolvelib-based dependency processing of constraints with hashes fails to "see" the exact pins pip#9243, tracked since 2020 resolver does not consider hashes in the constraints file pip#8792/#9020), merged 2026-04-17.

Both are pre-existing installer bugs, not something introduced or fixed by this PR — build passes the constraints file through unchanged either way; what a given installer version does with a hash sourced from a constraint is outside build's control.

Practically: if you rely on --dependency-constraints-txt for hash verification, you need pip ≥ 26.1 or uv ≥ 0.4.6. Below those versions the hash is silently not enforced (uv, pre-#7093) or the build refuses to proceed at all (pip, pre-#13887) — either way, not a build issue, and not something build can or should detect or work around on older installers.