Setup pypi publishing#5
Conversation
|
we already have a workflow file at https://github.com/ionq/ionq-core-python/blob/main/.github/workflows/release.yml. let's use that one. please just keep the readme changes. |
| (1) There is a CI/CD action that runs on every new tag and publishes the package to PyPi: | ||
| ```sh | ||
| git tag v0.1.0 | ||
| git push origin v0.1.0 | ||
| ``` |
There was a problem hiding this comment.
let's add some recommendations here on what standard format we want to use for alpha/beta releases, might be worth chatting about this during standup
@splch curious to hear your thoughts
…ify version tag matches pyproject version and version is not already on PyPI.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
splch
left a comment
splch
left a comment
There was a problem hiding this comment.
Review: #5 (revised)
Revised after clarification: the library is ionq-core; the repo stays ionq-core-python. There will be sibling repos (ionq-core-cpp, ionq-core-rust, etc.). Git/repo URLs use ionq-core-python; package name, user-agent, and headings use ionq-core.
Must Fix
1. Incomplete rename - openapi-python-client-config.yaml not updated
openapi-python-client-config.yaml:1 still has project_name_override: ionq-core-python. Since the library name is ionq-core, this should be updated to match. It controls the code generator's notion of the project name and will cause confusion during regen.
2. PyPI availability check lacks network resilience
The verify-version script catches urllib.error.HTTPError but not urllib.error.URLError (DNS failure, connection refused, network unreachable) or TimeoutError. If PyPI is temporarily unreachable, the release fails with an unhelpful stack trace instead of a clear warning. A transient network blip should not block a release.
Suggested fix:
except urllib.error.HTTPError as exc:
if exc.code != 404:
raise
except urllib.error.URLError as exc:
print(f"WARNING: Could not reach PyPI to check for duplicates: {exc}")3. "PyPi" misspelling in README
Two instances in the added publishing section use "PyPi" instead of the official capitalization "PyPI" (Python Package Index).
Should Fix
4. verify-version job installs full project dependencies unnecessarily
The inline Python script uses only stdlib modules (os, pathlib, tomllib, urllib). But uv run python triggers a full uv sync first, installing httpx, attrs, pytest, ruff, etc. This wastes time on every release. Use python3 directly (setup-uv already installs Python), or uv run --no-project python to skip project dependency installation.
5. Release workflow only tests on Python 3.12
The CI workflow (ci.yml) tests against 3.12, 3.13, and 3.14. The release workflow only tests on 3.12 before publishing. If a regression only manifests on 3.13+, it ships to PyPI undetected. Consider matching the CI matrix, or at least noting this as a known tradeoff.
6. test job now sequentially depends on verify-version
Adding needs: verify-version to test means a tag-version mismatch blocks tests entirely. Consider running verify-version and test in parallel (both as independent jobs), with build requiring both:
build:
needs: [verify-version, test]This gives faster feedback - you see test failures even when the tag is wrong.
Nit
7. README publishing section prose
- Missing comma: "For a new build to be accepted at PyPI**,** the version number..."
- "In principle you can also publish the package to PyPI manually using the uv package manager but the automatic approach is recommended." - either provide the command or drop the sentence.
- Extra trailing blank line before
## License.
8. Commit hygiene
9 commits including duplicate messages ("Update README." x2, "Fix Github CI action yaml warnings." x2) and a merge commit. Please squash before merge.
9. Empty PR body
No description of what the PR does, why the package is being renamed, or what the verify-version job adds.
|
- Replace 50-line Python verify script with 10-line shell equivalent - Remove job-level name: fields (no other workflow uses them) - Remove unnecessary step names on self-explanatory actions - Remove unnecessary contents: read from publish job permissions - Drop setup-uv from verify-version (only needs stdlib python3) - Use ::error:: annotations consistent with generated.yml - PyPI unreachable is a no-op instead of a release blocker
- Remove test job from release workflow (CI already gates merges to main) - Bump upload-artifact v6 -> v7, download-artifact v6 -> v8 - Add if-no-files-found: error to catch silent build failures
- astral-sh/setup-uv v8.0.0 -> v8.1.0 (all workflows) - actions/upload-pages-artifact v3 -> v5 (docs) - actions/deploy-pages v4 -> v5 (docs) - zizmorcore/zizmor-action v0.5.2 -> v0.5.3 (zizmor)
3 participants
Summary: