chore: add PyPI publishing infrastructure for wren-core-py#1496
chore: add PyPI publishing infrastructure for wren-core-py#1496douenergy merged 4 commits intoCanner:mainfrom
Conversation
Add package metadata, local publish script, and CI workflow to enable publishing wren-core-py to PyPI as a standalone package. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
github-actions
bot
added
documentation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughAdds publishing infrastructure and package metadata for Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant Runner as Build Runner
participant Art as Artifact Storage
participant PyPI as PyPI/TestPyPI
rect rgba(200,230,201,0.5)
Dev->>GH: trigger workflow (manual `workflow_dispatch`)
end
GH->>Runner: start matrixed build-wheels & build-sdist jobs
Runner->>Art: upload per-target wheel artifacts
Runner->>Art: upload sdist artifact
Art->>GH: artifacts available
GH->>GH: publish job downloads artifacts into consolidated `dist/`
GH->>PyPI: invoke pypa publishing action (repository-url chosen by `target`)
PyPI-->>GH: publish result
GH-->>Dev: workflow completion and logs
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/pypi-publish.yml:
- Around line 34-38: The job matrix uses an invalid runner label "macos-13" for
the x86_64 job (the entry paired with target: x86_64-apple-darwin); update that
runner label to a valid hosted runner such as "macos-latest" (or "macos-12") so
the workflow can start correctly—i.e., replace the "macos-13" value with a
supported label next to the x86_64-apple-darwin target.
In `@wren-core-py/README.md`:
- Around line 17-28: The example in README.md calls to_manifest(base64_mdl_json)
but never defines base64_mdl_json; update the snippet to show how to construct
base64_mdl_json (e.g., create the MDL manifest as a JSON string or dict,
serialize it to JSON, base64-encode that payload) and place that definition
immediately above the to_manifest call so readers can run the example; reference
the existing example symbols (to_manifest, SessionContext, transform_sql) and
ensure the added lines produce a variable named base64_mdl_json used by the
to_manifest call.
In `@wren-core-py/scripts/publish.sh`:
- Around line 95-101: The current block runs `twine check "$DIST_DIR"/*` and
treats any failure as "twine not available" when MODE=build, which masks real
validation errors; change the logic to first detect whether the `twine` command
exists (e.g., via `command -v twine` or checking exit status 127) and only
suppress validation in build mode when `twine` is genuinely missing; if `twine`
exists but `twine check` returns non-zero, always treat that as a validation
failure (exit non-zero) regardless of MODE, and if `twine` is missing and
MODE==build emit the warning you already have. Reference: the `twine check`
invocation, the `MODE` variable and `DIST_DIR` glob in the failing block.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 85071781-b16c-4fcc-801e-f88956c315b2
📒 Files selected for processing (5)
.github/workflows/pypi-publish.ymlwren-core-py/Cargo.tomlwren-core-py/README.mdwren-core-py/pyproject.tomlwren-core-py/scripts/publish.sh
.github/workflows/pypi-publish.yml
Outdated
| - os: macos-13 | ||
| target: x86_64-apple-darwin | ||
| # macOS arm64 | ||
| - os: macos-latest | ||
| target: aarch64-apple-darwin |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify workflow syntax and runner labels
actionlint -color -oneline .github/workflows/pypi-publish.ymlRepository: Canner/wren-engine
Length of output: 856
Invalid macOS runner label will break the wheel matrix.
Line 34 uses macos-13, which is not a valid GitHub Actions hosted runner label, so that job will fail to start.
💡 Proposed fix
- - os: macos-13
+ - os: macos-15-intel
target: x86_64-apple-darwin
@@
- - os: macos-latest
+ - os: macos-15
target: aarch64-apple-darwin🧰 Tools
🪛 actionlint (1.7.11)
[error] 34-34: label "macos-13" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2025-vs2026", "windows-2022", "windows-11-arm", "ubuntu-slim", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "macos-latest", "macos-latest-xlarge", "macos-latest-large", "macos-26-xlarge", "macos-26-large", "macos-26", "macos-15-intel", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xlarge", "macos-14-large", "macos-14", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/pypi-publish.yml around lines 34 - 38, The job matrix uses
an invalid runner label "macos-13" for the x86_64 job (the entry paired with
target: x86_64-apple-darwin); update that runner label to a valid hosted runner
such as "macos-latest" (or "macos-12") so the workflow can start correctly—i.e.,
replace the "macos-13" value with a supported label next to the
x86_64-apple-darwin target.
wren-core-py/scripts/publish.sh
Outdated
| twine check "$DIST_DIR"/* 2>/dev/null || { | ||
| if [[ "$MODE" == "build" ]]; then | ||
| echo "Warning: twine not available for validation (build-only mode)" | ||
| else | ||
| exit 1 | ||
| fi | ||
| } |
There was a problem hiding this comment.
Validation failures are masked in --build mode.
This block treats any twine check failure as “twine not available” when MODE=build, so real metadata/package errors can pass silently.
💡 Proposed fix
-echo "==> Validating with twine check"
-twine check "$DIST_DIR"/* 2>/dev/null || {
- if [[ "$MODE" == "build" ]]; then
- echo "Warning: twine not available for validation (build-only mode)"
- else
- exit 1
- fi
-}
+echo "==> Validating with twine check"
+if command -v twine &>/dev/null; then
+ twine check "$DIST_DIR"/*
+elif [[ "$MODE" == "build" ]]; then
+ echo "Warning: twine not installed; skipping validation in build-only mode"
+else
+ echo "Error: 'twine' is not installed. Run: pip install twine" >&2
+ exit 1
+fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@wren-core-py/scripts/publish.sh` around lines 95 - 101, The current block
runs `twine check "$DIST_DIR"/*` and treats any failure as "twine not available"
when MODE=build, which masks real validation errors; change the logic to first
detect whether the `twine` command exists (e.g., via `command -v twine` or
checking exit status 127) and only suppress validation in build mode when
`twine` is genuinely missing; if `twine` exists but `twine check` returns
non-zero, always treat that as a validation failure (exit non-zero) regardless
of MODE, and if `twine` is missing and MODE==build emit the warning you already
have. Reference: the `twine check` invocation, the `MODE` variable and
`DIST_DIR` glob in the failing block.
- Replace invalid macos-13 runner with macos-15-intel - Fix twine check error handling in publish.sh to not mask validation errors Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2 participants
Summary
wren-core-py/pyproject.tomlandCargo.toml(description, license, classifiers, project URLs)README.mdwith installation instructions, quick start example, and publishing guidescripts/publish.shfor local build + publish to PyPI/TestPyPI.github/workflows/pypi-publish.ymlCI workflow (builds wheels for Linux x86_64/arm64, macOS x86_64/arm64, Windows x86_64 via maturin-action, publishes with trusted publisher OIDC)Package is already verified on TestPyPI: https://test.pypi.org/project/wren-core-py/
Test plan
maturin build --releasesucceeds locallymaturin sdistsucceeds locallypip install --index-url https://test.pypi.org/simple/ wren-core-pypypi-publish.ymlworkflow manually to verify CI build matrix🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Chores