chore: add .python-version so Snyk resolves deps correctly

[ryanmcmillan]

Root Cause

Snyk is resolving dependencies as Python 3.7.17 (visible in project settings). At Python 3.7, packages like pydantic and sqlalchemy need the importlib-metadata backport, which pulls zipp@3.15.0 (CVE-2024-5569).

On Python 3.9+, these packages use stdlib importlib.metadata and never touch zipp.

Fix

Add .python-version file set to 3.14 so Snyk resolves the dependency tree with the correct Python version. Our Dockerfile runs python:3.14.3-slim.

[greptile-apps]

Greptile Summary

This PR adds a .python-version file set to 3.14 to fix Snyk's dependency resolution, which was incorrectly defaulting to Python 3.7.17 and pulling in the importlib-metadata backport (and transitively zipp@3.15.0, CVE-2024-5569). The fix is correct and consistent with the production Dockerfile (python:3.14.3-slim).

• The root cause and fix are well-explained and the change is minimal and targeted.
• The .python-version value (3.14) matches the Dockerfile's base image (python:3.14.3-slim), confirming alignment between Snyk resolution, local dev tooling, and production.
• One gap worth addressing: the CI matrix in .github/workflows/ci.yml tests only 3.10, 3.11, and 3.12. Now that .python-version points to 3.14, developers running locally and the production container are both on 3.14, but that version is never exercised in CI. Adding 3.14 to the matrix would close this gap.
• requirements.txt retains a zipp>=3.19.1 pin from a previous fix — this is harmless but may become unnecessary once Snyk correctly resolves via Python 3.14 and no longer surfaces zipp at all.

Confidence Score: 5/5

• Safe to merge — this is a single-line config file change with no runtime impact, correctly targeting a Snyk false-positive caused by incorrect Python version resolution.
• The change is minimal (one config file, one line), aligns with the production Dockerfile, and carries no execution risk. The only concern is a pre-existing CI matrix gap that is worth fixing in a follow-up but does not block this PR.
• No files require special attention; optionally review .github/workflows/ci.yml to add Python 3.14 to the test matrix as a follow-up.

Important Files Changed

Filename	Overview
.python-version	Adds .python-version set to 3.14 to guide Snyk's dependency resolution to the correct Python version, matching the Dockerfile. Note that CI still tests on 3.10–3.12 only, creating a minor version discrepancy for local development.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Snyk scans repo] --> B{.python-version present?}
    B -- No --> C[Snyk assumes Python 3.7.17]
    B -- Yes --> D[Snyk uses Python 3.14]
    C --> E[importlib-metadata backport required for pydantic and sqlalchemy]
    D --> F[stdlib importlib.metadata used - no backport needed]
    E --> G[zipp 3.15.0 pulled in as transitive dep]
    F --> H[zipp never pulled in]
    G --> I[CVE-2024-5569 flagged]
    H --> J[No CVE - clean scan]

Loading

_{Last reviewed commit: "chore: add .python-v..."}

[greptile-apps]

CI matrix does not include Python 3.14

The .python-version file pins local development (and Snyk resolution) to Python 3.14, which correctly matches the Dockerfile (python:3.14.3-slim). However, the CI workflow in .github/workflows/ci.yml only tests against ['3.10', '3.11', '3.12'].

This means:

• Developers using pyenv will run Python 3.14 locally based on this file.
• CI validates a different set of Python versions (3.10–3.12), none of which match the production runtime.

If Python 3.14-specific behaviour (e.g. deprecations, removed APIs) causes a regression, it won't be caught by CI. Consider adding 3.14 to the CI matrix to keep local dev, CI, and production in sync:

matrix:
  python-version: ['3.10', '3.11', '3.12', '3.14']