Default the SDK version to the contract's info.version - #43
Conversation
UltralyticsAssistant
added
documentation
|
👋 Hello @glenn-jocher, thank you for submitting a
For more guidance, please refer to our Contributing Guide. Don't hesitate to leave a comment if you have any questions. Thank you for contributing to Ultralytics! 🚀 |
UltralyticsAssistant
left a comment
UltralyticsAssistant
left a comment
There was a problem hiding this comment.
🔍 PR Review
Made with ❤️ by Ultralytics Actions
Reviewed all four changed files and the config-to-generator flow. The optional override is wired consistently, but the new default does not validate that an OpenAPI document version is usable as Python package metadata, leaving a realistic SDK build failure path.
💬 Posted 1 inline comment
- 💡 MEDIUM
lib/generators/python.ts:847info.versionis only constrained to be a string identifying the OpenAPI document, while[project].versionmust use Python's packaging version format. A valid contract value such asrelease-2026-08-15or1.2.3-alpha.1will therefore generate a package that fails atuv build/publish whenpython.versionis omitted. Validate the fallback as a Python-compatible version and fail with an actionable error, or require an explicitpython.versionoverride for incompatible contract versions.…
| Bun.write( | ||
| `${output}/pyproject.toml`, | ||
| `[build-system]\nrequires = ["uv_build>=0.12.3,<0.13"]\nbuild-backend = "uv_build"\n\n[project]\nname = "${config.python.project}"\nversion = "${config.python.version}"\n${projectMetadata}\nreadme = "README.md"\nlicense = "${license.id}"\nlicense-files = ["LICENSE"]\ndependencies = ["httpx>=0.28,<1"]${projectUrls}\n\n[tool.ruff]\nline-length = 120\n\n[tool.uv.build-backend]\nmodule-name = "${config.python.package}"\n`, | ||
| `[build-system]\nrequires = ["uv_build>=0.12.3,<0.13"]\nbuild-backend = "uv_build"\n\n[project]\nname = "${config.python.project}"\nversion = "${config.python.version ?? document.info.version}"\n${projectMetadata}\nreadme = "README.md"\nlicense = "${license.id}"\nlicense-files = ["LICENSE"]\ndependencies = ["httpx>=0.28,<1"]${projectUrls}\n\n[tool.ruff]\nline-length = 120\n\n[tool.uv.build-backend]\nmodule-name = "${config.python.package}"\n`, |
There was a problem hiding this comment.
💡 MEDIUM: info.version is only constrained to be a string identifying the OpenAPI document, while [project].version must use Python's packaging version format. A valid contract value such as release-2026-08-15 or 1.2.3-alpha.1 will therefore generate a package that fails at uv build/publish when python.version is omitted. Validate the fallback as a Python-compatible version and fail with an actionable error, or require an explicit python.version override for incompatible contract versions. (spec.openapis.org)
There was a problem hiding this comment.
Now validated: when python.version is omitted and info.version is not a valid Python package version, generation fails with Set python.version: contract version "…" is not a valid Python package version.
|
🎉 Thanks @glenn-jocher—the PR has been merged!
This update makes the OpenAPI contract’s |
## Summary Removes the hard-coded `python.version` from `openapi.config.json`: with ultralytics/openapi#43 the generator defaults the package version to the contract's `info.version`, so the API version is the single source of truth and a contract bump reaching `main` publishes the SDK. README wording updated. Also re-pins the live contract snapshot (now `info.version` 0.1.5 via ultralytics/portal#3620, plus the authored examples from ultralytics/portal#3619) and regenerates: only docstring example text in five resource modules changes; the package version stays 0.1.5, so no publish is triggered. Depends on ultralytics/openapi#43 (CI regenerates from `openapi` `main`). ## Verification `sha256sum --check`, `ruff check`, `pytest tests` (4 passed); regenerated `pyproject.toml` reports `version = "0.1.5"` from the contract.
2 participants
Summary
The API contract's
info.versionand the generated SDK's package version were two hand-maintained numbers and had already drifted (0.1.3vs0.1.5, ultralytics/portal#3620). This makespython.versionoptional: when omitted, the generatedpyproject.tomltakes the contract'sinfo.version, so bumping the version in the API is the single source of truth and flows through the sdk repo's contract sync → regen → publish chain.lib/config.ts:python.versionoptional (dropped from the required-key check).lib/generators/python.ts:version = config.python.version ?? document.info.version.Companion: ultralytics/sdk removes its hard-coded
"version"(regenerated output stays 0.1.5 since the live contract now reports 0.1.5).Verification
bun run test|typecheck|lint|knippass; regenerating with the sdk config (still pinning 0.1.5) yieldsversion = "0.1.5", and with the key removed the live contract's0.1.5is used.🛠️ PR Summary
Made with ❤️ by Ultralytics Actions
🌟 Summary
Python SDK generation now defaults
python.versionto the OpenAPI contract’sinfo.version, making the contract the default version source while retaining explicit configuration overrides.📊 Key Changes
python.versionoptional and removed it from the required configuration keys.config.python.versionwhen provided, otherwisedocument.info.version.🎯 Purpose & Impact
python.version; generatedpyproject.tomlthen receives the contract’sinfo.version.python.versionvalues continue to override the contract version.python.version.