ERROR: Ignored the following versions that require a different python version: 4.19.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement pymongo==4.19.0
Cause
base.Dockerfile was still on python:3.10, but the pinned pymongo==4.19.0 requires Python >= 3.11. The requirements were pinned in the previous PR (to stop an unpinned dependency changing behaviour under a deploy) and that exposed the version gap.
Fix
The base image is now python:3.14-slim — the current stable release, so the image is not carrying the CVEs fixed in 3.11, 3.12 and 3.13.
All the runtime dependencies ship a cp314 wheel (pymongo included), so the compiler toolchain the old image installed is no longer needed:
libsasl2-dev, python-dev-is-python3, libldap2-dev and libssl-dev were only there for packages that are no longer in the dependency list, so that apt-get line is gone and the image is smaller.
The build now asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message instead of a pip resolution error.
Files changed
base.Dockerfile — the Python version, the removed toolchain install, the version assertion
Note
This is deliberately a one-file change so the broken build on master can be unblocked on its own, independently of the feature work. The build job only runs on master, so it will not fire on this branch — it fires when this merges.
## Summary
Fixes the failing image build on `master`.
### The error
```
ERROR: Ignored the following versions that require a different python version: 4.19.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement pymongo==4.19.0
```
### Cause
`base.Dockerfile` was still on `python:3.10`, but the pinned `pymongo==4.19.0` requires Python >= 3.11. The requirements were pinned in the previous PR (to stop an unpinned dependency changing behaviour under a deploy) and that exposed the version gap.
### Fix
The base image is now `python:3.14-slim` — the current stable release, so the image is not carrying the CVEs fixed in 3.11, 3.12 and 3.13.
All the runtime dependencies ship a cp314 wheel (pymongo included), so the compiler toolchain the old image installed is no longer needed:
```
$ pip download --python-version 3.14 --only-binary=:all: \
flask==3.1.3 Flask-WTF==1.3.0 waitress==3.0.2 pymongo==4.19.0 requests==2.32.5
Saved /tmp/wheels314/pymongo-4.19.0-cp314-cp314-manylinux2014_x86_64.whl
Successfully downloaded flask Flask-WTF waitress pymongo requests
```
`libsasl2-dev`, `python-dev-is-python3`, `libldap2-dev` and `libssl-dev` were only there for packages that are no longer in the dependency list, so that apt-get line is gone and the image is smaller.
The build now asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message instead of a pip resolution error.
## Files changed
- `base.Dockerfile` — the Python version, the removed toolchain install, the version assertion
## Note
This is deliberately a one-file change so the broken build on `master` can be unblocked on its own, independently of the feature work. The `build` job only runs on `master`, so it will not fire on this branch — it fires when this merges.
The image build failed on master:
ERROR: Ignored the following versions that require a different python
version: 4.19.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement
pymongo==4.19.0
The base image was `python:3.10` but the pinned pymongo 4.19 needs Python
>= 3.11. The image is now `python:3.14-slim` — the current stable release,
so it is not carrying the CVEs fixed in 3.11, 3.12 and 3.13.
All the runtime dependencies ship a cp314 wheel (pymongo included), so no
compiler toolchain is needed. The old apt-get line installed
libsasl2-dev, python-dev-is-python3, libldap2-dev and libssl-dev for
packages that are no longer in the dependency list, so it is gone and the
image is smaller.
The build now asserts the interpreter version, so a base image change that
breaks the pinned requirements fails the build with a clear message rather
than a pip resolution error.
Consolidated Code Review Report: Base Image Upgrade
Executive Summary
The proposed changes aim to resolve a build failure caused by a version mismatch between the Python base image and the pymongo dependency. While the PR correctly identifies the need to upgrade Python and makes positive strides in reducing the image's attack surface and size, it introduces a critical stability and security risk by targeting Python 3.14, which is currently an alpha/development release.
All three review domains (Code, Security, and Infrastructure) are in unanimous agreement: the use of a pre-release runtime in a production-track branch is unacceptable. Additionally, the report identifies gaps in the CI/CD pipeline and image pinning strategies that must be addressed to ensure build reproducibility and stability.
Prioritized List of Issues
🔴 CRITICAL
Use of Experimental Runtime (Python 3.14): The PR targets Python 3.14, which is in alpha/beta. This introduces significant risks of runtime instability, unvetted security vulnerabilities, and potential incompatibility with third-party binary wheels.
Lack of PR Validation: Infrastructure review noted that the build job only runs on master. Merging an infrastructure change without branch-level validation is a high-risk pattern.
🟠 HIGH
Floating Image Tags: The use of python:3.14-slim allows the underlying OS and Python micro-version to change without notice, leading to non-deterministic builds.
Runtime Library Risk: The removal of -dev packages (e.g., libssl-dev) based solely on the availability of wheels may inadvertently remove shared libraries required at runtime.
🟡 MEDIUM
Suboptimal Version Assertion: Implementing a shell-script version check in the Dockerfile is considered a "band-aid" solution compared to using pyproject.toml or .python-version files.
🔵 LOW
Build Tooling Management: The current approach of removing toolchains entirely is less flexible than using a multi-stage build.
Domain-Specific Recommendations
💻 Code Quality
Downgrade to Stable: Immediately change the base image to python:3.12-slim or python:3.13-slim. These satisfy the pymongo >= 3.11 requirement.
Formalize Versioning: Move the Python version assertion from a Dockerfile shell script to a standard configuration file (e.g., pyproject.toml using requires-python).
Verify Runtime Dependencies: Explicitly test the final image to ensure that removing -dev packages did not break the application's ability to link to SSL or LDAP shared libraries.
🛡️ Security
Strict Versioning: Only use Stable or LTS versions of runtimes in production.
Immutable Pinning: Transition from tags (e.g., :slim) to SHA256 digests (e.g., python:3.13-slim@sha256:...) to prevent base image poisoning and ensure consistency.
Automated Scanning: Integrate CVE scanners (e.g., Trivy, Grype) into the pipeline to automatically flag unstable or vulnerable base images.
🏗️ Infrastructure
CI/CD Pipeline Fix: Update the CI configuration to execute the build job on all Pull Requests, not just on the master branch.
Adopt Multi-Stage Builds: Implement a two-stage Dockerfile:
Builder Stage: Install all compilers and -dev libraries to build wheels.
Runtime Stage: Copy only the compiled site-packages into a fresh slim image. This minimizes the attack surface while maintaining the ability to compile from source.
Positive Aspects of the PR
Root Cause Analysis: Correctly identified the version mismatch between the Python interpreter and pymongo.
Attack Surface Reduction: The intent to remove unnecessary build-time system dependencies is a security and performance best practice.
Proactive Validation: The addition of a version assertion, while suboptimal in placement, shows a desire to prevent silent failures in the future.
Overall Assessment & Recommendation
Overall Rating: ❌ Significant Changes Needed
Recommendation: This PR cannot be merged in its current state. The transition to an alpha version of Python (3.14) represents an unacceptable risk to production stability and security.
Required Actions for Approval:
Revert the base image to a stable version (3.12 or 3.13).
Pin the image to a specific micro-version or SHA digest.
Update the CI pipeline to allow validation of the build on the PR branch.
(Optional but Highly Recommended) Refactor the Dockerfile into a multi-stage build.
## PR Review Results
# Consolidated Code Review Report: Base Image Upgrade
## Executive Summary
The proposed changes aim to resolve a build failure caused by a version mismatch between the Python base image and the `pymongo` dependency. While the PR correctly identifies the need to upgrade Python and makes positive strides in reducing the image's attack surface and size, it introduces a **critical stability and security risk** by targeting **Python 3.14**, which is currently an alpha/development release.
All three review domains (Code, Security, and Infrastructure) are in unanimous agreement: the use of a pre-release runtime in a production-track branch is unacceptable. Additionally, the report identifies gaps in the CI/CD pipeline and image pinning strategies that must be addressed to ensure build reproducibility and stability.
---
## Prioritized List of Issues
### 🔴 CRITICAL
* **Use of Experimental Runtime (Python 3.14):** The PR targets Python 3.14, which is in alpha/beta. This introduces significant risks of runtime instability, unvetted security vulnerabilities, and potential incompatibility with third-party binary wheels.
* **Lack of PR Validation:** Infrastructure review noted that the build job only runs on `master`. Merging an infrastructure change without branch-level validation is a high-risk pattern.
### 🟠 HIGH
* **Floating Image Tags:** The use of `python:3.14-slim` allows the underlying OS and Python micro-version to change without notice, leading to non-deterministic builds.
* **Runtime Library Risk:** The removal of `-dev` packages (e.g., `libssl-dev`) based solely on the availability of wheels may inadvertently remove shared libraries required at runtime.
### 🟡 MEDIUM
* **Suboptimal Version Assertion:** Implementing a shell-script version check in the Dockerfile is considered a "band-aid" solution compared to using `pyproject.toml` or `.python-version` files.
### 🔵 LOW
* **Build Tooling Management:** The current approach of removing toolchains entirely is less flexible than using a multi-stage build.
---
## Domain-Specific Recommendations
### 💻 Code Quality
* **Downgrade to Stable:** Immediately change the base image to `python:3.12-slim` or `python:3.13-slim`. These satisfy the `pymongo >= 3.11` requirement.
* **Formalize Versioning:** Move the Python version assertion from a Dockerfile shell script to a standard configuration file (e.g., `pyproject.toml` using `requires-python`).
* **Verify Runtime Dependencies:** Explicitly test the final image to ensure that removing `-dev` packages did not break the application's ability to link to SSL or LDAP shared libraries.
### 🛡️ Security
* **Strict Versioning:** Only use Stable or LTS versions of runtimes in production.
* **Immutable Pinning:** Transition from tags (e.g., `:slim`) to SHA256 digests (e.g., `python:3.13-slim@sha256:...`) to prevent base image poisoning and ensure consistency.
* **Automated Scanning:** Integrate CVE scanners (e.g., Trivy, Grype) into the pipeline to automatically flag unstable or vulnerable base images.
### 🏗️ Infrastructure
* **CI/CD Pipeline Fix:** Update the CI configuration to execute the `build` job on all Pull Requests, not just on the `master` branch.
* **Adopt Multi-Stage Builds:** Implement a two-stage Dockerfile:
1. **Builder Stage:** Install all compilers and `-dev` libraries to build wheels.
2. **Runtime Stage:** Copy only the compiled site-packages into a fresh `slim` image. This minimizes the attack surface while maintaining the ability to compile from source.
---
## Positive Aspects of the PR
* **Root Cause Analysis:** Correctly identified the version mismatch between the Python interpreter and `pymongo`.
* **Attack Surface Reduction:** The intent to remove unnecessary build-time system dependencies is a security and performance best practice.
* **Proactive Validation:** The addition of a version assertion, while suboptimal in placement, shows a desire to prevent silent failures in the future.
---
## Overall Assessment & Recommendation
**Overall Rating: ❌ Significant Changes Needed**
**Recommendation:** This PR **cannot be merged** in its current state. The transition to an alpha version of Python (3.14) represents an unacceptable risk to production stability and security.
**Required Actions for Approval:**
1. Revert the base image to a stable version (3.12 or 3.13).
2. Pin the image to a specific micro-version or SHA digest.
3. Update the CI pipeline to allow validation of the build on the PR branch.
4. (Optional but Highly Recommended) Refactor the Dockerfile into a multi-stage build.
Two follow-ups to the review of the base image change.
1. Pin the patch version: `python:3.14-slim` is a floating tag, so a rebuild
could silently pick up a different base image. It is now
`python:3.14.10-slim`, so a rebuild is reproducible.
2. Run the app as an unprivileged user. The app only reads its own source
and talks to Mongo over the network — it writes no files — so it does not
need to be root. A `beer` system user is created and the image ends with
`USER beer`.
ERROR: Ignored the following versions that require a different python version: 4.19.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement pymongo==4.19.0
Cause
base.Dockerfile was still on python:3.10, but the pinned pymongo==4.19.0 requires Python >= 3.11. The requirements were pinned in an earlier PR — to stop an unpinned dependency changing behaviour under a deploy — and that exposed the version gap.
Fix
The base image is now python:3.14.10-slim.
On the Python version. The independent review flagged Python 3.14 as "an alpha/developmental stage" and recommended 3.13. That is not correct, and I checked the official sources rather than taking it at face value:
3.14 is a stable release in its normal maintenance phase and receives security fixes until 2030. 3.13 and 3.12 are further along — in the security-only phase — meaning they get no further bugfix releases, only CVE patches. So 3.14 is the more current and better-maintained choice of the two, not the riskier one.
Patch version pinned.python:3.14.10-slim rather than the floating 3.14-slim tag, so a rebuild is reproducible and cannot silently pick up a base image change.
Toolchain removed. All the runtime dependencies ship a cp314 wheel, so the compiler toolchain the old image installed is no longer needed. The apt-get line installed libsasl2-dev, python-dev-is-python3, libldap2-dev and libssl-dev for packages that are no longer in the dependency list, so it is gone and the image is smaller.
Non-root user. The app only reads its own source and talks to Mongo over the network — it writes no files — so it does not need to be root. A beer system user is created and the image ends with USER beer.
Version assertion. The build asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message rather than a pip resolution error.
Not done here
Multi-stage build — the dependency set needs no compiler, so a builder stage would add complexity without shrinking the image further. The --no-cache-dir flag already keeps pip's cache out of the layers.
Image vulnerability scanning — worth doing, but it needs a scanner image and a place to publish the results, which is a workflow change rather than a Dockerfile one. Noted as a follow-up.
Files changed
base.Dockerfile — Python version and patch pin, toolchain removal, version assertion
flask.Dockerfile — the non-root user
Test plan
The wheel availability for 3.14 was checked directly (output above)
The app entrypoint was verified against the same pinned dependency set: waitress --call beer_data:create_app serves the app and /healthz and /login both return 200
The app uses no stdlib modules removed in 3.12+, and no datetime.utcnow()
The real proof: the image must build and run on the cluster. The build job only runs on master, so it fires when this merges. I will watch it and report the outcome.
## Summary
Fixes the failing image build on `master`.
### The error
```
ERROR: Ignored the following versions that require a different python version: 4.19.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement pymongo==4.19.0
```
### Cause
`base.Dockerfile` was still on `python:3.10`, but the pinned `pymongo==4.19.0` requires Python >= 3.11. The requirements were pinned in an earlier PR — to stop an unpinned dependency changing behaviour under a deploy — and that exposed the version gap.
### Fix
The base image is now `python:3.14.10-slim`.
**On the Python version.** The independent review flagged Python 3.14 as "an alpha/developmental stage" and recommended 3.13. That is not correct, and I checked the official sources rather than taking it at face value:
- [Python 3.14.0 release page](https://www.python.org/downloads/release/python-3140/): "Release date: Oct. 7, 2025 — This is the stable release of Python 3.14.0".
- [Python devguide — Status of Python versions](https://devguide.python.org/versions/): 3.14 is in the **bugfix** phase (first release 2025-10-07, end of life 2030-10).
3.14 is a stable release in its normal maintenance phase and receives security fixes until 2030. 3.13 and 3.12 are further along — in the *security*-only phase — meaning they get no further bugfix releases, only CVE patches. So 3.14 is the more current and better-maintained choice of the two, not the riskier one.
**Patch version pinned.** `python:3.14.10-slim` rather than the floating `3.14-slim` tag, so a rebuild is reproducible and cannot silently pick up a base image change.
**Toolchain removed.** All the runtime dependencies ship a cp314 wheel, so the compiler toolchain the old image installed is no longer needed. The `apt-get` line installed `libsasl2-dev`, `python-dev-is-python3`, `libldap2-dev` and `libssl-dev` for packages that are no longer in the dependency list, so it is gone and the image is smaller.
```
$ pip download --python-version 3.14 --only-binary=:all: \
flask==3.1.3 Flask-WTF==1.3.0 waitress==3.0.2 pymongo==4.19.0 requests==2.32.5
Saved /tmp/wheels314/pymongo-4.19.0-cp314-cp314-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl
Successfully downloaded flask Flask-WTF waitress pymongo requests
```
**Non-root user.** The app only reads its own source and talks to Mongo over the network — it writes no files — so it does not need to be root. A `beer` system user is created and the image ends with `USER beer`.
**Version assertion.** The build asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message rather than a pip resolution error.
### Not done here
- **Multi-stage build** — the dependency set needs no compiler, so a builder stage would add complexity without shrinking the image further. The `--no-cache-dir` flag already keeps pip's cache out of the layers.
- **Image vulnerability scanning** — worth doing, but it needs a scanner image and a place to publish the results, which is a workflow change rather than a Dockerfile one. Noted as a follow-up.
## Files changed
- `base.Dockerfile` — Python version and patch pin, toolchain removal, version assertion
- `flask.Dockerfile` — the non-root user
## Test plan
- [x] The wheel availability for 3.14 was checked directly (output above)
- [x] The app entrypoint was verified against the same pinned dependency set: `waitress --call beer_data:create_app` serves the app and `/healthz` and `/login` both return 200
- [x] The app uses no stdlib modules removed in 3.12+, and no `datetime.utcnow()`
- [ ] **The real proof: the image must build and run on the cluster.** The `build` job only runs on `master`, so it fires when this merges. I will watch it and report the outcome.
hermes
merged commit 0f93cbea70 into master2026-11-09 11:26:29 +10:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Fixes the failing image build on
master.The error
Cause
base.Dockerfilewas still onpython:3.10, but the pinnedpymongo==4.19.0requires Python >= 3.11. The requirements were pinned in the previous PR (to stop an unpinned dependency changing behaviour under a deploy) and that exposed the version gap.Fix
The base image is now
python:3.14-slim— the current stable release, so the image is not carrying the CVEs fixed in 3.11, 3.12 and 3.13.All the runtime dependencies ship a cp314 wheel (pymongo included), so the compiler toolchain the old image installed is no longer needed:
libsasl2-dev,python-dev-is-python3,libldap2-devandlibssl-devwere only there for packages that are no longer in the dependency list, so that apt-get line is gone and the image is smaller.The build now asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message instead of a pip resolution error.
Files changed
base.Dockerfile— the Python version, the removed toolchain install, the version assertionNote
This is deliberately a one-file change so the broken build on
mastercan be unblocked on its own, independently of the feature work. Thebuildjob only runs onmaster, so it will not fire on this branch — it fires when this merges.The image build failed on master: ERROR: Ignored the following versions that require a different python version: 4.19.0 Requires-Python >=3.11 ERROR: Could not find a version that satisfies the requirement pymongo==4.19.0 The base image was `python:3.10` but the pinned pymongo 4.19 needs Python >= 3.11. The image is now `python:3.14-slim` — the current stable release, so it is not carrying the CVEs fixed in 3.11, 3.12 and 3.13. All the runtime dependencies ship a cp314 wheel (pymongo included), so no compiler toolchain is needed. The old apt-get line installed libsasl2-dev, python-dev-is-python3, libldap2-dev and libssl-dev for packages that are no longer in the dependency list, so it is gone and the image is smaller. The build now asserts the interpreter version, so a base image change that breaks the pinned requirements fails the build with a clear message rather than a pip resolution error.PR received — starting review, sit tight 🫡
PR Review Results
Consolidated Code Review Report: Base Image Upgrade
Executive Summary
The proposed changes aim to resolve a build failure caused by a version mismatch between the Python base image and the
pymongodependency. While the PR correctly identifies the need to upgrade Python and makes positive strides in reducing the image's attack surface and size, it introduces a critical stability and security risk by targeting Python 3.14, which is currently an alpha/development release.All three review domains (Code, Security, and Infrastructure) are in unanimous agreement: the use of a pre-release runtime in a production-track branch is unacceptable. Additionally, the report identifies gaps in the CI/CD pipeline and image pinning strategies that must be addressed to ensure build reproducibility and stability.
Prioritized List of Issues
🔴 CRITICAL
master. Merging an infrastructure change without branch-level validation is a high-risk pattern.🟠 HIGH
python:3.14-slimallows the underlying OS and Python micro-version to change without notice, leading to non-deterministic builds.-devpackages (e.g.,libssl-dev) based solely on the availability of wheels may inadvertently remove shared libraries required at runtime.🟡 MEDIUM
pyproject.tomlor.python-versionfiles.🔵 LOW
Domain-Specific Recommendations
💻 Code Quality
python:3.12-slimorpython:3.13-slim. These satisfy thepymongo >= 3.11requirement.pyproject.tomlusingrequires-python).-devpackages did not break the application's ability to link to SSL or LDAP shared libraries.🛡️ Security
:slim) to SHA256 digests (e.g.,python:3.13-slim@sha256:...) to prevent base image poisoning and ensure consistency.🏗️ Infrastructure
buildjob on all Pull Requests, not just on themasterbranch.-devlibraries to build wheels.slimimage. This minimizes the attack surface while maintaining the ability to compile from source.Positive Aspects of the PR
pymongo.Overall Assessment & Recommendation
Overall Rating: ❌ Significant Changes Needed
Recommendation: This PR cannot be merged in its current state. The transition to an alpha version of Python (3.14) represents an unacceptable risk to production stability and security.
Required Actions for Approval:
Summary
Fixes the failing image build on
master.The error
Cause
base.Dockerfilewas still onpython:3.10, but the pinnedpymongo==4.19.0requires Python >= 3.11. The requirements were pinned in an earlier PR — to stop an unpinned dependency changing behaviour under a deploy — and that exposed the version gap.Fix
The base image is now
python:3.14.10-slim.On the Python version. The independent review flagged Python 3.14 as "an alpha/developmental stage" and recommended 3.13. That is not correct, and I checked the official sources rather than taking it at face value:
3.14 is a stable release in its normal maintenance phase and receives security fixes until 2030. 3.13 and 3.12 are further along — in the security-only phase — meaning they get no further bugfix releases, only CVE patches. So 3.14 is the more current and better-maintained choice of the two, not the riskier one.
Patch version pinned.
python:3.14.10-slimrather than the floating3.14-slimtag, so a rebuild is reproducible and cannot silently pick up a base image change.Toolchain removed. All the runtime dependencies ship a cp314 wheel, so the compiler toolchain the old image installed is no longer needed. The
apt-getline installedlibsasl2-dev,python-dev-is-python3,libldap2-devandlibssl-devfor packages that are no longer in the dependency list, so it is gone and the image is smaller.Non-root user. The app only reads its own source and talks to Mongo over the network — it writes no files — so it does not need to be root. A
beersystem user is created and the image ends withUSER beer.Version assertion. The build asserts the interpreter version, so a future base image change that breaks the pinned requirements fails with a clear message rather than a pip resolution error.
Not done here
--no-cache-dirflag already keeps pip's cache out of the layers.Files changed
base.Dockerfile— Python version and patch pin, toolchain removal, version assertionflask.Dockerfile— the non-root userTest plan
waitress --call beer_data:create_appserves the app and/healthzand/loginboth return 200datetime.utcnow()buildjob only runs onmaster, so it fires when this merges. I will watch it and report the outcome.