Keep the lockfile's rationale where a compile cannot wipe it
All checks were successful
CI / naming (push) Successful in 4s
CI / frontend (push) Successful in 13s
CI / migrations-mysql (push) Successful in 40s
CI / backend (push) Successful in 4m12s

requirements.txt carried a hand-written header explaining why the lockfile is
universal and hashed, what each flag buys, and a warning not to hand-edit it
because waitress and tzdata were once added by hand and vanished on the next
compile.

Running `uv pip compile` to upgrade two packages wiped all of it, including the
warning about hand-edits vanishing. The header had been documenting its own
failure mode and still lost.

The explanation now lives in requirements.in, which is the file people edit and
which a compile never rewrites. The header is restored in requirements.txt for
anyone reading that file directly, but it is no longer the only copy.

Also records the --upgrade-package form for moving one package without moving
everything else, and the scan_sbom.py check to run before a release.
This commit is contained in:
cproudlock
2026-08-29 17:42:43 -04:00
parent b8fc2e9e33
commit 76d34a4b25

View File

@@ -1,3 +1,28 @@
# DIRECT requirements only. requirements.txt is COMPILED from this file:
#
# uv pip compile requirements.in --universal --generate-hashes -o requirements.txt
#
# Upgrade one package without moving everything else:
#
# uv pip compile requirements.in --universal --generate-hashes \
# --upgrade-package <name> -o requirements.txt
#
# This explanation lives HERE, not in requirements.txt, because a compile
# rewrites that file from scratch. The same guidance was written into its
# header once and was silently wiped by the next `uv pip compile` - including
# the line warning that hand-edits vanish. It is restored there for readers,
# but this copy is the one that survives.
#
# Only DIRECT requirements belong in this file. A runtime import satisfied in
# dev only because some test dependency happens to pull it in will pass every
# test and then fail on a production venv: `packaging` reached this project
# through pytest, and the Windows install could not import shopdb at all until
# it was declared. tests/test_runtime_dependencies.py guards that.
#
# Check dependencies against published advisories before a release:
#
# venv/bin/python scripts/scan_sbom.py --gate
# Flask and extensions
flask>=3.0
flask-sqlalchemy>=3.1