Summary
The entire detection container is pinned to Python 3.9, which reached end-of-life on 2025-10-31. This is not a routine dependency lag — it's a structural constraint with no clean fix available today.
Root cause
pycoral and tflite_runtime (Google's Coral Edge TPU inference libraries) are abandoned upstream and only ever published cp39 wheels:
tflite_runtime-2.5.0.post1-cp39-cp39-linux_x86_64.whlpycoral-2.0.0-cp39-cp39-linux_x86_64.whl
No newer wheels exist for Python 3.10+, and the upstream repos have seen no meaningful releases in years.
Downstream effects (all confirmed, not theoretical)
- numpy is locked to the 1.x line (currently
1.26.4, the last 1.x release). pycoral's compiled bindings (_pywrap_coral.cpython-39-*.so) are built against the numpy 1.x C ABI. A numpy 2.x upgrade was tried (to unblock a newer opencv pin) and broke at runtime on the actual Coral TPU hardware — this is invisible to pip's resolver, which only checks declared version ranges, not compiled ABI compatibility.
- opencv-python-headless is capped at
4.9.0.80 as a consequence of (1): the 4.12.x line requires numpy>=2, so we're stuck below that. 4.9.0.80 predates CVE-2025-53644 (which only affects 4.10.0/4.11.0), so this isn't a regression to a known-vulnerable version, but it does mean we can't take opencv's latest security/bugfix releases going forward without hitting the same wall.
- Pillow is capped at
11.3.0 (last release with cp39 wheels; 12.x dropped Python 3.9).
- Every other pinned dependency (
requests, paho-mqtt, shapely) has to be re-checked against cp39 wheel availability on every bump.
Why this can't be fixed as a normal dependency bump
Moving off Python 3.9 requires replacing the Coral inference stack entirely — there is no newer pycoral/tflite_runtime to upgrade to. Realistic paths forward:
- Wait for (or contribute to) a community fork of pycoral with newer Python wheels.
- Migrate to the standalone
tflite-runtime package from tensorflow proper if/when it regains Coral delegate support for modern Python.
- Replace the Coral TPU inference path with a different runtime (e.g. ONNX Runtime + a different accelerator, or plain CPU/GPU inference if TPU speed is no longer required).
- Stay on Python 3.9 indefinitely, running it in a container image that's otherwise kept current everywhere else (current approach), accepting that the base interpreter itself is unsupported upstream.
Current mitigation
Dockerfile pins every dependency to the newest version that still ships a cp39 (or cp37-abi3, which is cp39-compatible) wheel, and documents the numpy/opencv ABI constraint inline.README.md "Known limitations" section documents this pin and the numpy/opencv/Pillow caps it forces.- No action item here beyond periodic re-checking — this issue exists to track the risk explicitly rather than let it live only in code comments, and to link future work if a path off Python 3.9 becomes viable.
Suggested next check-in
Revisit when either:
pycoral/tflite_runtime ship any release targeting Python 3.10+, or- Python 3.9 is fully removed from
python:3.9-slim-bookworm's upstream support (Debian bookworm's own EOL), forcing a base image change regardless.
Summary
The entire detection container is pinned to Python 3.9, which reached end-of-life on 2025-10-31. This is not a routine dependency lag — it's a structural constraint with no clean fix available today.
Root cause
pycoralandtflite_runtime(Google's Coral Edge TPU inference libraries) are abandoned upstream and only ever publishedcp39wheels:tflite_runtime-2.5.0.post1-cp39-cp39-linux_x86_64.whlpycoral-2.0.0-cp39-cp39-linux_x86_64.whlNo newer wheels exist for Python 3.10+, and the upstream repos have seen no meaningful releases in years.
Downstream effects (all confirmed, not theoretical)
1.26.4, the last 1.x release). pycoral's compiled bindings (_pywrap_coral.cpython-39-*.so) are built against the numpy 1.x C ABI. A numpy 2.x upgrade was tried (to unblock a newer opencv pin) and broke at runtime on the actual Coral TPU hardware — this is invisible topip's resolver, which only checks declared version ranges, not compiled ABI compatibility.4.9.0.80as a consequence of (1): the 4.12.x line requiresnumpy>=2, so we're stuck below that. 4.9.0.80 predates CVE-2025-53644 (which only affects 4.10.0/4.11.0), so this isn't a regression to a known-vulnerable version, but it does mean we can't take opencv's latest security/bugfix releases going forward without hitting the same wall.11.3.0(last release withcp39wheels; 12.x dropped Python 3.9).requests,paho-mqtt,shapely) has to be re-checked against cp39 wheel availability on every bump.Why this can't be fixed as a normal dependency bump
Moving off Python 3.9 requires replacing the Coral inference stack entirely — there is no newer
pycoral/tflite_runtimeto upgrade to. Realistic paths forward:tflite-runtimepackage fromtensorflowproper if/when it regains Coral delegate support for modern Python.Current mitigation
Dockerfilepins every dependency to the newest version that still ships acp39(orcp37-abi3, which is cp39-compatible) wheel, and documents the numpy/opencv ABI constraint inline.README.md"Known limitations" section documents this pin and the numpy/opencv/Pillow caps it forces.Suggested next check-in
Revisit when either:
pycoral/tflite_runtimeship any release targeting Python 3.10+, orpython:3.9-slim-bookworm's upstream support (Debian bookworm's own EOL), forcing a base image change regardless.