chore: test Python 3.14 in CI and declare supported versions on PyPI - #67
Merged
Merged
Conversation
Three metadata and coverage gaps found while releasing 3.5.0. The CI matrix stopped at 3.13 while requires-python is ">=3.10" with no upper bound, so 3.14 users were installing and running the SDK unverified. Confirmed 3.14.7 passes everything before adding it: 450 offline tests, 33 perf tests, mypy clean over 87 files, pylint 10.00/10 on the errors-only gate, and a clean-room install of the published 3.5.0 wheel running a documented example against the live API. actions/python-versions carries 3.14.7, so setup-python resolves it. The package declared no classifiers at all, so PyPI could not filter it by Python version and the project page showed no supported-version metadata. Requires-Python was already correct and is what pip and uv resolve against, so this is discoverability rather than installability. No `License ::` trove classifier: the SPDX `license` expression already emits `License-Expression`, and declaring both is what newer setuptools warns about. Verified all ten classifiers and the four URLs land in the built wheel's METADATA. No project URLs were declared either, so PyPI showed no Homepage, Repository, Changelog or Issues links. Homepage points at the canonical https://you.com/docs/welcome rather than https://you.com/docs, which 301s. Metadata only: uv.lock is unchanged (`uv lock --check` clean), the build emits no warnings, and the version stays at 3.5.0 -- these take effect with the next release rather than re-cutting one already on PyPI.
Contributor
|
Droid finished @tyler5673's task —— View job Pass 2 validation complete. LGTM, no high-confidence issues found. This PR is low risk and limited to CI coverage (Python 3.14) plus PyPI metadata (classifiers and project URLs). No inline review comments to post (0 candidates). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the 3.5.0 release. Three metadata and coverage gaps surfaced while shipping it; none affect the published 3.5.0 artifacts, so they land here rather than in a re-cut.
1. CI never tested Python 3.14
requires-python = ">=3.10"has no upper bound, so 3.14 users install and run this SDK today — while the matrix stopped at 3.13. I verified 3.14 before adding it rather than adding it and hoping:mypy src/ scripts/actions/python-versionscarries 3.14.7, sosetup-pythonresolves it. The clean-room run is how this gap got noticed at all — it installed 3.5.0 under 3.14 and exercised the knowledge path against prod.No upper bound on
requires-pythonstays as-is, which is right for a library: 3.15.0rc1 exists and capping would block users for no reason unless something actually breaks.2. The package declared zero classifiers
PyPI could not filter it by Python version and the project page showed no supported-version metadata.
Requires-Pythonwas already correct and is what pip/uv resolve against, so this is discoverability, not installability — worth being precise about, since it means nothing was broken for users.Ten classifiers added, covering 3.10–3.14 plus
Typing :: Typed(py.typedships) andOperating System :: OS Independent(pure Python).No
License :: OSI Approved :: MIT Licensetrove: the SPDXlicense = "MIT"expression already emitsLicense-Expression, and declaring both is what newer setuptools warns about. Verified the built METADATA carriesLicense-Expression: MITand no conflicting classifier.3. No project URLs
PyPI showed no Homepage, Repository, Changelog or Issues links. Added all four.
Homepagepoints at the canonicalhttps://you.com/docs/welcomerather thanhttps://you.com/docs, which 301s.Verification
pyproject.tomlparses;uv lock --checkclean — the lock does not need regeneratingProject-URLs, andLicense-Expression: MIT['3.10', '3.11', '3.12', '3.13', '3.14'];build-checkanddrift-checkstay pinned at 3.12Not in this PR
versionstays at3.5.0. These are metadata-only and take effect with the next release; re-cutting 3.5.0 is not possible anyway, since PyPI versions are immutable and 3.5.0 is already published with verified hashes.