feat(sdk): accept python 3.13 as a target version

[deanq]

Summary

Adds Python 3.13 to the SDK's supported target versions. Strictly additive — non-breaking. Users opt in by declaring python_version="3.13" on a resource; default deploy behavior is unchanged.

What's in this PR

• core/resources/constants.py: add "3.13" to SUPPORTED_PYTHON_VERSIONS, GPU_PYTHON_VERSIONS, CPU_PYTHON_VERSIONS. DEFAULT_PYTHON_VERSION, WORKER_PYTHON_VERSION, and GPU_BASE_IMAGE_PYTHON_VERSION remain "3.12".
• pyproject.toml: requires-python = ">=3.10,<3.14". Add Programming Language :: Python :: 3.13 (and 3.12) classifier.
• Tests: assert validate_python_version("3.13") succeeds, _reconcile_python_version accepts a python_version="3.13" resource declaration, image-name resolution for 3.13 yields runpod/flash:py3.13-latest. The previously-existing "invalid version" sentinel tests were flipped from "3.13" to "3.9".
• CI: python-version matrix in ci.yml and release-please.yml extended to include 3.13.

Why

Extracted from AE-2827 / #330 so 3.13 support can land independently of the broader match-local-by-default work (which is a BREAKING CHANGE and still in flight on #330). This PR has no breaking changes.

Pairs with flash-worker #98 which publishes the py3.13-* Docker image variants.

Release coordination

Both PRs can merge to main in any order. The only ordering constraint is between the release-please PRs:

1. flash-worker release-please merges first → Docker Hub publishes runpod/flash:py3.13-{gpu,cpu,lb,lb-cpu}.
2. flash release-please merges → PyPI publishes new SDK that accepts python_version="3.13".

If the SDK release lands first, no user can hit a broken state until they explicitly set python_version="3.13", which would then pull a missing image tag. Reversing the release order eliminates that window.

Linear

AE-3152 (child of AE-2827)

Test plan

• CI green on 3.10/3.11/3.12/3.13
• validate_python_version("3.13") returns "3.13"
• _reconcile_python_version accepts python_version="3.13" on a resource
• After flash-worker py3.13 release → manual end-to-end deploy of a LiveServerless(python_version="3.13", ...) succeeds and handler returns a response

[promptless]

Promptless prepared a documentation update related to this change.

Triggered by PR #338

Updated 6 documentation files to reflect Python 3.13 support in the Flash SDK, replacing "coming soon" notices with actual support documentation.

Review: Flash Python 3.13 support

[Copilot]

Pull request overview

Adds Python 3.13 as an opt-in target/runtime version for the Flash SDK, updating version validation, image-name resolution, packaging metadata, CI matrices, and accompanying unit tests. Default behavior remains pinned to Python 3.12.

Changes:

• Extend supported/CPU/GPU Python version constants to include "3.13" and validate "3.13" for image name resolution.
• Broaden packaging metadata (requires-python) and update GitHub Actions matrices to test on Python 3.13.
• Update unit tests to cover "3.13" acceptance and shift “invalid version” sentinels away from "3.13".

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/runpod_flash/core/resources/constants.py	Adds 3.13 to supported/CPU/GPU version lists used for validation and image resolution.
pyproject.toml	Expands requires-python to <3.14 and adds Python 3.12/3.13 classifiers.
tests/unit/core/resources/test_constants.py	Updates constants/image/version-validation tests to include 3.13 and adjusts invalid-version cases.
tests/unit/cli/commands/build_utils/test_manifest.py	Adds a unit test ensuring _reconcile_python_version accepts a 3.13 resource declaration.
tests/unit/resources/test_serverless.py	Updates invalid-version test sentinel away from 3.13.
.github/workflows/ci.yml	Extends CI test matrix to include Python 3.13.
.github/workflows/release-please.yml	Extends release workflow quality gate matrix to include Python 3.13.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[runpod-Henrik]

Henrik's AI-Powered Bug Finder — PR #338 Review

Verdict: PASS WITH NITS

Strictly additive change as described. Defaults unchanged (DEFAULT_PYTHON_VERSION=3.12, WORKER_PYTHON_VERSION=3.12, GPU_BASE_IMAGE_PYTHON_VERSION=3.12), so existing users hit no new code paths. The 3.13 opt-in path is gated on the matching worker images publishing first — that's the only real failure mode and the PR description already calls it out.

CI green on all four versions (3.10/3.11/3.12/3.13). Validation, image-name resolution, and _reconcile_python_version all have new tests.

---

1. Issue: docs still claim "3.10, 3.11, or 3.12" — copy-paste examples will mislead 3.13 users

User scenario: a user reads the deploy guide after the SDK release, sees the supported-versions table missing 3.13, and doesn't realise they can opt in. Or worse — sees the SDK accept python_version="3.13" at install/build but trusts the doc's "supported" list and never tries it.

Stale references in this repo:

• README.md:165 — "Python 3.10-3.12"
• docs/Flash_Deploy_Guide.md:9 — "Python 3.10, 3.11, or 3.12"
• docs/Flash_Deploy_Guide.md:22-24 — supported-versions table is missing a 3.13 row
• docs/Deployment_Architecture.md:34 — comment lists "3.10 / 3.11 / 3.12"

CLAUDE.md:7 says "Python >=3.10 <3.13" but that file is auto-generated, so leave it for the next `/analyze-repos` pass.

Worth a one-commit doc sweep before merging — the SDK side will accept 3.13 the moment this lands.

---

2. Issue: deadsnakes comment doesn't match Deploy Guide's "+~7 GB" overhead claim

Constants comment now reads "3.10, 3.11, and 3.13 are available via side-by-side install (deadsnakes PPA)" (constants.py:4-6), but docs/Flash_Deploy_Guide.md:22-23 still says non-3.12 versions add "+~7 GB alt-Python install" overhead.

If the worker side really moved to deadsnakes (lighter), the deploy-guide cost column is stale. If it didn't, then this PR's comment update is misleading. Worth confirming against flash-worker #98 which version of the story is true and aligning both.

---

3. Question: release ordering enforcement

PR description correctly notes the gate: flash-worker release-please PR must merge first so `runpod/flash:py3.13-{gpu,cpu,lb,lb-cpu}` exist by the time SDK validates `python_version="3.13"`.

If a user runs `flash deploy` with `python_version="3.13"` after the SDK ships but before the worker images publish, what's the failure shape? My read: validation passes, image name resolves to `runpod/flash:py3.13-latest`, deploy attempts the pull, and the platform returns an image-not-found at endpoint provisioning time — not at SDK validation. Is there a way to verify the image tag exists before submitting (e.g., on `flash deploy` preflight), or are we relying entirely on the release ordering discipline?

Not a blocker — just confirming the failure path is "platform-level error" rather than "silent fallback to a different tag."

---

4. Question: torch wheel availability for 3.13 in the side-by-side path

For non-3.12 targets the worker reinstalls torch side-by-side. Torch 3.13 wheels exist starting 2.5.0 (Oct 2024), so if flash-worker pins or floats to a version that has 3.13 wheels, this works. If the worker uses an older torch pin, the `pip install torch` step on 3.13 falls back to source build and either times out or fails.

Out of scope for this PR (worker concern), but worth a one-line check on flash-worker #98 that the torch install line resolves a 3.13 wheel.

---

Nits

• `tests/unit/core/resources/test_constants.py:90` — `test_invalid_python_version_raises` now uses `"3.9"` as the known-bad version. That's a real Python version users might genuinely try, so the test name "invalid" is slightly off. `"3.99"` (which the other test uses at line 136) is a cleaner sentinel. Consistency would be nice.
• `pyproject.toml:11-14` — adding explicit `3.10/3.11/3.12/3.13` classifiers is good. Worth dropping a `Programming Language :: Python :: 3 :: Only` while you're at it for PyPI completeness, but not blocking.
• `src/runpod_flash/core/resources/constants.py:13` comment "Base image ships 3.12 with torch pre-installed; non-3.12 targets reinstall torch side-by-side" — does the deadsnakes path also reinstall torch, or pull a different wheel? The two adjacent comments (lines 4-6 vs 11-14) describe two different mechanisms (~7 GB alt-Python overhead → deadsnakes PPA) without saying whether they coexist or one replaced the other. Worth one extra sentence.

---

🤖 Reviewed by Henrik's AI-Powered Bug Finder

[deanq]

Addressed Henrik's review in 0292416:

Item 1 — docs sweep: Updated README.md, docs/Flash_Deploy_Guide.md (prereqs + version table), and docs/Deployment_Architecture.md to include Python 3.13.

Item 2 — deadsnakes vs "+~7 GB": Aligned the deploy guide and constants.py with the actual flash-worker reality (per flash-worker/docs/System_Python_Runtime_Architecture.md): the GPU base image already ships 3.9-3.14 side-by-side via deadsnakes PPA, so the real cold-start overhead for non-3.12 targets is a torch wheel reinstall against the matching ABI (cp310/cp311/cp313), not an alternate-interpreter install. Updated the table column accordingly.

Q1 — release ordering failure shape: Your read is correct. SDK-side validation passes (3.13 is in SUPPORTED_PYTHON_VERSIONS), get_image_name("gpu", "3.13") resolves to runpod/flash:py3.13-latest, and the failure surfaces at endpoint provisioning when the platform can't pull the tag — not a silent fallback. There is no preflight tag-existence check today. We're relying on the release-ordering discipline (flash-worker AE-2827 sibling PR merges first, publishing py3.13-* tags before this SDK ships). Adding a preflight Docker Hub HEAD check on flash deploy is worth a follow-up if we see this footgun in practice, but I don't want to bake the registry coupling into the SDK preemptively.

Q2 — torch wheel for 3.13: Tracking on the flash-worker side. Torch 2.5.0+ ships cp313 wheels (Oct 2024); the sibling worker PR's torch pin will need to clear that floor. Will surface it on flash-worker #98 explicitly.

Nits:

• test_constants.py:90 — switched "3.9" → "3.99" to match the line-136 sentinel
• constants.py:11-14 — rewrote the two adjacent comment blocks so the deadsnakes interpreter install and the per-ABI torch reinstall are described as distinct mechanisms that coexist
• pyproject.toml — added Programming Language :: Python :: 3 :: Only classifier