test(ci): add a non-gating Python 3.15 lane to evaluate adopting the interpreter

Open
  • Is something wrong?
#3,600 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions, python
Domain
ci-cd, testing

Research direction

Start with the tests job in .github/workflows/ci.yml (around line 242) and the note at line 335 about CI installing no Python, then read requires-python and the ruff and ty settings in pyproject.toml. Look at tests/image/test_dockerfile_uv_pins.py (test_all_uv_pins_agree_across_arches) and tests/jobs/capture_operations/test_manifest.py (around line 1080) to see which tests hard-code 3.14. Done means a non-gating 3.15 lane runs and reports results while the 3.14 gate stays unchanged, and the findings are recorded in the PR.

Written by the indexing model from the issue text.

Description

area:core-platform effort:M priority:P3 risk:daytime-only status:ready type:test

Problem

CPython 3.15 is released (3.15.0 on 2026-10-09, 3.15.2 current per endoflife.date). kdive is 3.14-only by contract and has no signal on whether 3.15 works: nothing in CI runs the suite under 3.15, so adoption can only be judged by merging a dependency bump and watching it fail. Dependabot PR #2096 (docker-images group, python:3.15.0-slim-bookworm) is open and fails exactly this way: test_all_uv_pins_agree_across_arches, test_docker_and_ansible_generate_after_final_interpreter, and the CI image smoke. Those failures are the 3.14-only contract working as written, not 3.15 incompatibilities, so they say nothing about 3.15 itself.

No existing issue covers this (searched open and closed for "3.15", "python 3.15", "python:3.15", "interpreter", "matrix", "requires-python"; the nearest hits are unrelated interpreter-path or #2818/#2819 release-qualification matrix issues).

Evidence

  • pyproject.toml:12 pins requires-python = "==3.14.*"; pyproject.toml:63 sets ruff target-version = "py314"; [tool.ty.environment] at pyproject.toml:78 sets only python-platform = "linux", so ty takes its Python version from requires-python.
  • Dockerfile:16, :21, :80 and tests/container/Dockerfile:6 pin python:3.14.6-slim-bookworm@sha256:....
  • tests/jobs/capture_operations/test_manifest.py:1080 hard-codes the string FROM python:3.14.6-slim-bookworm; tests/image/test_dockerfile_uv_pins.py:42 (test_all_uv_pins_agree_across_arches) and tests/jobs/capture_operations/test_manifest.py:1073 encode the single-interpreter contract. Other tests that mention 3.14: tests/image/test_dockerfile_apt_https.py, tests/images/test_drgn_support.py, tests/scripts/test_check_setup_deps.py, tests/scripts/test_setup_developer.py, tests/scripts/test_live_workflow_shape.py, tests/deploy/*provisioning*.py, tests/processes/lifecycle/systemd/*.py.
  • .github/workflows/ci.yml:335 documents that CI installs no Python (setup-uv takes no python-version, no actions/setup-python) and relies on requires-python; .github/workflows/live.yml:47 notes live lanes depend on a system 3.14 (Ubuntu 26.04). ADR-0578 and ADR-0692 (EL10 python3.14 libguestfs binding) record why.
  • Native dependency 3.15 availability on PyPI (checked 2026-11-12): drgn 0.3.0 ships cp315 and cp315t manylinux wheels (repo pins 0.2.0 in pyproject.toml:55); psycopg-binary 3.3.9 ships cp315 wheels (repo pins psycopg[binary]==3.3.4, :15); cryptography 50.0.2 ships abi3 wheels (cp311-abi3, usable on 3.15; repo pins 50.0.0, :19); libvirt-python 12.9.0 is sdist-only (repo pins 12.5.0, :22), so it compiles against system libvirt headers on any interpreter. The pinned versions were not individually checked for cp315 wheels; the current releases above are the evidence that 3.15 support exists upstream.

Expected

A non-gating, clearly labelled 3.15 lane runs the ordinary suite (and lint/type where applicable) under CPython 3.15 and reports pass/fail, without weakening the 3.14-only contract for the default lane and release images. The result tells the project, with evidence, whether to adopt 3.15, and tells Dependabot #2096 what is actually blocking it.

Proposed approach

One PR, test/CI only, no change to the shipped interpreter:

  1. Add a CI job (or a matrix leg on the existing tests job at ci.yml:242) that runs uv run --python 3.15 --no-project-style or uv sync --python 3.15 with an override that relaxes requires-python for that lane only (for example a --config-file/UV_* override or a generated pyproject patch in the job), marked continue-on-error so it is informational. Keep the 3.14 lane gating.
  2. Run unit tests under 3.15 with warnings surfaced (3.15 deprecations/removals), and ty check --python-version 3.15 plus ruff check --target-version py315 as read-only probes.
  3. Add a container smoke lane building tests/container/Dockerfile with a 3.15 base via build-arg, to show the image builds with psycopg[binary], cryptography, and libvirt-python (sdist build) on 3.15.
  4. Record in the PR the first-run findings: which tests fail under 3.15 and why, split into (a) contract tests that hard-code 3.14 (test_manifest.py:1080, test_dockerfile_uv_pins.py:42) versus (b) genuine 3.15 incompatibilities, and the list of pins (drgn, psycopg, cryptography, libvirt-python) that must be bumped for cp315 wheels.
  5. Out of scope: actually changing requires-python, the Dockerfile base images, or ruff/ty targets, and the live/EL10 guestfs binding (ADR-0692) which needs a 3.15 system binding; file follow-ups from the findings instead. Closing or rebasing #2096 is decided after the findings land.

Risk: risk:daytime-only (CI workflow change plus an interpreter-override mechanism that must not leak into the gating lane).

Dominant language
Python
Stars
0
Forks
0
Avg merge
9h 13m
Merged PRs (30d)
197

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from randomparity/kdive

All issues in randomparity/kdive

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.