Mohd Kaif
d135ad185f
* fix(ci): drop unpinnable benchmarks/requirements.txt install Scorecard flagged this pip install as unpinned-by-hash (#6082). Can't hash-pin it - benchmarks/requirements.txt doesn't exist in this repo, so there's nothing to compile a lockfile from. Dropping it instead of leaving it unpinned: the job already fails on the next real step (benchmarks/benchmarks_runner.py, also missing), so this line wasn't doing anything useful to begin with. * fix(ci): hash-pin the spacy model download in benchmark.yml Qodo review on this PR: dropping the benchmarks/requirements.txt install (the previous failure point) let the job actually reach `python -m spacy download en_core_web_sm`, which fetches an unpinned, unhashed wheel from spacy-models' GitHub releases - undoing the point of this PR by exposing a real unpinned-install path instead of a dead one. Replaced with a hash-pinned direct-URL entry in benchmark-extra.in/.txt for en_core_web_sm-3.8.0 (matches the spacy==3.8.15 already pinned in base-deps.txt). uv independently computed the same sha256 I got via a manual curl+sha256 of the release asset, and a --require-hashes dry-run install verifies clean.
CI tool requirements
Hash-pinned pip install targets for CI/release/Dockerfile steps that install
something other than the project's own audited requirements-ci.txt set.
These exist because OpenSSF Scorecard's Pinned-Dependencies check flags any
pip install in a workflow or Dockerfile that isn't hash-verified, and
requirements-ci.txt alone doesn't cover build/release/security tooling or
the project's own local-source install.
Each .txt was generated from the adjacent .in (or, for explorer-extra-py311.txt,
explorer-extra-py313.txt, and base-deps.txt, from pyproject.toml directly) with:
uv pip compile <input> --python-version 3.11 --python-platform linux \
--constraint requirements-ci.txt --generate-hashes -o <output>.txt
(--constraint requirements-ci.txt is omitted for bootstrap.txt,
build-tools.txt, uv-tool.txt, twine.txt, pip-audit.txt, and
security-scan-tools.txt, since those install standalone tooling with no
version relationship to the project's own dependency tree.)
Regenerate a file the same way after bumping a pinned version, and re-run it
whenever requirements-ci.txt changes if the file used --constraint (see
each file's own autogenerated header comment for its exact command).
| File | Used by | Installs |
|---|---|---|
bootstrap.txt |
security.yml, security-scan.yml, benchmark.yml | pip, setuptools (upgrade before anything else) |
pep517-build.txt |
ci.yml, benchmark.yml, Dockerfile | exact [build-system] requires from pyproject.toml (setuptools, wheel) - installed with --no-build-isolation before any pip install -e . / pip install ., since --no-deps alone doesn't stop pip's PEP 517 build isolation from fetching those two unhashed |
explorer-extra-py311.txt |
ci.yml | semantica's base deps + the explorer extra, resolved for python 3.11 |
explorer-extra-py313.txt |
Dockerfile | the same, resolved for python 3.13 (the image's actual interpreter) |
pytest-tool.txt |
ci.yml | pytest, for the pre-all-extras deterministic test |
uv-tool.txt |
ci.yml | uv, to verify requirements-ci.txt is current |
build-tools.txt |
ci.yml, release.yml | build, wheel |
twine.txt |
release.yml | twine |
pip-audit.txt |
security.yml | pip-audit |
security-scan-tools.txt |
security-scan.yml | safety, bandit, semgrep, jq |
base-deps.txt |
benchmark.yml | semantica's base deps (no extras) |
benchmark-extra.txt |
benchmark.yml | the benchmark-only libs (neo4j, pdfplumber, etc.) |
explorer-extra-py31{1,3}.txt and base-deps.txt are large (they mirror
most of requirements-ci.txt) because semantica's dependencies list in
pyproject.toml isn't extras-gated - installing the package at all pulls
the full base set. That's expected, not a mistake.
explorer-extra-py311.txt and explorer-extra-py313.txt are not
interchangeable, and can't be collapsed into one file compiled for either
version: librosa's audioread dependency needs standard-aifc /
standard-sunau only under python_version >= "3.13" (Python 3.13 dropped
aifc/sunau from stdlib). A file resolved for 3.11 simply omits those
packages' hashes, so installing it with --require-hashes on a real 3.13
interpreter (the Dockerfile's base image) fails outright rather than
silently under-pinning. Any other file shared across a 3.11 and 3.13
consumer would need the same split if it hits a similar stdlib-removal
edge case - check for ERROR: In --require-hashes mode, all requirements must have their versions pinned on the other Python version before
assuming one --python-version covers every consumer.