Mohd KaifandClaude Sonnet 5
b8011eb44a
#1290 bumped the runtime stage to python:3.14-slim. gensim is a base (non-extras-gated) dependency and publishes no cp314 wheel on PyPI, so pip falls back to building it from source, which needs a C compiler this slim image doesn't carry: error: [Errno 2] No such file or directory: 'gcc' This has broken the Docker build (and Container Security Scan) on every push to main since #1290 merged. Confirmed via `pip index versions gensim` / the PyPI files listing that gensim 4.4.0 ships cp313 wheels but no cp314 ones; the earlier lockfile fix in #1290 only validated that `uv pip compile` could *resolve* dependencies for 3.14, which reads sdist metadata and doesn't need a compiler -- it doesn't validate that `pip install` can actually *build* them, which is what fails here. Reverts to the exact base image digest that was building successfully before #1290 and regenerates explorer-extra-py313.txt against today's PyPI state. Once gensim (and anything else pulled in transitively) ships cp314 wheels, the 3.14 bump can be retried. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
3.5 KiB
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-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-scan.yml | pip-audit |
security-scan-tools.txt |
security-scan.yml | 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.