build(sdk): register arcbox (Python) as a release-please component - #551
build(sdk): register arcbox (Python) as a release-please component#551AprilNEA wants to merge 1 commit into
Conversation
Component sdk-python, release-type python, own tag namespace (sdk-python-vX.Y.Z, include-component-in-tag), seeded in the manifest at the package's current 0.1.0, and excluded from the root release's paths — mirroring the sdk-typescript registration. README gains the Releasing section: the release-please flow, the tag-triggered publish workflow (lands separately), and the PyPI pending-trusted-publisher bootstrap — registered before the first upload, so CI does the first publish with no local bootstrap and no API token, unlike npm.
Greptile SummaryRegisters the Python SDK as an independently versioned release-please component.
Confidence Score: 4/5The release activation should not merge until the tag-triggered Python publishing workflow is available, or the first SDK release will stop after creating its GitHub tag. The new component can create sdk-python release tags through the active release-please workflow, but no current workflow handles those tags or publishes the package to PyPI. Files Needing Attention: release-please-config.json and sdk/python/README.md
|
| Filename | Overview |
|---|---|
| release-please-config.json | Registers the Python component correctly, but activates release tags before the corresponding publishing workflow exists. |
| .release-please-manifest.json | Seeds the new component at the pyproject.toml version of 0.1.0. |
| sdk/python/README.md | Documents a CI-only PyPI release flow whose referenced workflow is not present in the repository. |
Sequence Diagram
sequenceDiagram
participant M as Maintainer
participant RP as release-please
participant GH as GitHub
participant WF as release-sdk-python.yml
participant PyPI
M->>RP: Merge generated SDK release PR
RP->>GH: Create sdk-python-vX.Y.Z tag and release
GH--xWF: No matching workflow exists
WF--xPyPI: No package publication
Reviews (1): Last reviewed commit: "build(sdk): register arcbox (Python) as ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| "sdk/python": { | ||
| "release-type": "python", | ||
| "component": "sdk-python", | ||
| "include-component-in-tag": true, | ||
| "changelog-path": "CHANGELOG.md" |
There was a problem hiding this comment.
When a maintainer merges the first generated sdk/python release PR, release-please creates the sdk-python-vX.Y.Z tag, but no checked-in workflow handles that tag or publishes the package, causing the GitHub release to complete without a corresponding PyPI release.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d1d28c6025
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "sdk/python": { | ||
| "release-type": "python", | ||
| "component": "sdk-python", | ||
| "include-component-in-tag": true, | ||
| "changelog-path": "CHANGELOG.md" |
There was a problem hiding this comment.
When this configuration reaches master, release-please can create and merge an sdk-python release PR and push its tag, but the reviewed tree contains no .github/workflows/release-sdk-python.yml (a repo-wide search found only the new README references). GitHub will therefore run no PyPI publisher for that tag, and adding the workflow later will not replay the missed tag-push event, leaving the GitHub release and manifest ahead of PyPI and preventing the documented pending-publisher bootstrap; land the workflow atomically or keep this component disabled until it exists.
Useful? React with 👍 / 👎.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℓ️ One follow-up worth tracking, plus two runbook nits.
Reviewed changes — config + docs only, 3 files, no runtime code; verified the release-please wiring against the tool's own source and the PyPI/GitHub contracts the README documents.
sdk/pythonregistered as a release-please package —release-type: python, componentsdk-python,include-component-in-tag: true,changelog-path: CHANGELOG.md.- Root package narrowed —
exclude-pathsgrows to["fleet", "sdk/python"]so SDK commits stop feeding the arcbox release train. - Manifest seeded at
0.1.0— matchessdk/python/pyproject.toml's[project] version. - New
## Releasingsection insdk/python/README.md— the component flow, the tag-triggered publish workflow (lands separately), and the PyPI pending-trusted-publisher bootstrap; the staleUV_PUBLISH_TOKENnote is retired.
The wiring itself checks out. release-type: python does bump a PEP 621 [project] version (release-please's PyProjectToml updater branches on parsed.project before falling back to tool.poetry, and this pyproject has a static version with no dynamic = ["version"]), so no extra-files entry is needed. The src/arcbox/__init__.py update the strategy also queues no-ops harmlessly since that file carries no __version__. sdk-python-v* follows the fleet-agent-v* precedent and does not collide with release.yml's tags: ['v*'] trigger. The PyPI name arcbox is currently unregistered (HTTP 404 on pypi.org/pypi/arcbox/json), and the README's pending-publisher field list matches PyPI's form exactly.
⚠️ uv.lock keeps the old project version after every release
sdk/python/uv.lock:20-21 pins name = "arcbox" / version = "0.1.0", and release-please's python strategy updates no lockfile — so each release PR bumps pyproject.toml while uv.lock keeps the previous version, and the release tag's tree ships the two disagreeing. This does not carry over from #546: the node strategy it mirrors updates package-lock.json natively, so the TypeScript registration has no equivalent gap. Nothing breaks today because every gate uses plain uv run (which silently re-locks), but it bites the moment one adopts uv sync --locked or uv run --frozen.
Technical details
# `uv.lock` project version is not maintained across releases
## Affected sites
- `sdk/python/uv.lock:20-21` — `[[package]] name = "arcbox"` / `version = "0.1.0"`; the
project's own version is recorded in its lockfile.
- `release-please-config.json:43-48` — the new `sdk/python` entry declares no version site
beyond what `release-type: python` handles natively.
- `.github/workflows/release-please.yml:31-68` — the repo's existing precedent: a dedicated
step regenerates `Cargo.lock` on every open release PR, commented "so its release tag can
build with `--locked`". There is no `uv.lock` equivalent.
## Evidence
- release-please's `python` strategy queues updates for the changelog, `setup.cfg`,
`setup.py`, `pyproject.toml`, `{pkg}/__init__.py`, `src/{pkg}/__init__.py`, discovered
`version.py` files, and `changelog.json` — no lockfile among them.
https://raw.githubusercontent.com/googleapis/release-please/main/src/strategies/python.ts
- The `node` strategy #546 uses does queue `package-lock.json` and `npm-shrinkwrap.json`.
https://raw.githubusercontent.com/googleapis/release-please/main/src/strategies/node.ts
## Required outcome
- After an `sdk-python-vX.Y.Z` tag is cut, `sdk/python/uv.lock`'s `arcbox` entry agrees with
`sdk/python/pyproject.toml`, so the tag's tree passes a `--locked` / `--frozen` gate.
## Suggested approach (optional)
- Land it with the follow-up `release-sdk-python.yml` PR rather than here — workflow files
cannot be pushed from this branch's token. Extending the existing lock-regeneration step in
`release-please.yml` to run `uv lock` inside `sdk/python` for the sdk-python release PR
reuses machinery that already exists for `Cargo.lock`.
- An `extra-files` entry is a poor fit: `uv.lock` is generated, so a `generic` updater's
`x-release-please-version` annotation would be clobbered on regeneration, and a `toml`
jsonpath into the `[[package]]` array depends on the alphabetical position of the `arcbox`
entry.
## Open questions for the human
- Is `--locked` / `--frozen` intended for the `sdk-python` CI gates (the README's
`TODO(CI)` at line 140)? If yes, this needs to be fixed before that job lands, not after.Claude Opus ｜ 𝕏
| 1. On pypi.org → account → Publishing → "Add a new pending publisher" | ||
| (GitHub): PyPI project name `arcbox`, owner `arcboxlabs`, repository | ||
| `arcbox`, workflow filename `release-sdk-python.yml`, environment | ||
| left empty. |
There was a problem hiding this comment.
PyPI's own docs call the environment field "optional but strongly recommended" — leaving it empty binds the trusted publisher to repo + workflow filename only, so any run of release-sdk-python.yml on any ref can mint a publish credential with no environment approval gate. Worth either setting an environment here (and matching it in the workflow) or stating why empty is deliberate.
| left empty. | ||
| 2. The first tag-triggered run then creates the `arcbox` project on | ||
| PyPI as it publishes, and the pending publisher becomes the | ||
| project's regular trusted publisher. Nothing else to configure. |
There was a problem hiding this comment.
A pending publisher does not reserve the name: per PyPI, it "does not create a project or reserve a project's name until it is actually used to publish," and if someone else registers arcbox first the pending publisher is invalidated. Since arcbox is short and generic and still unclaimed, worth a clause noting the first publish should follow registration promptly — "Nothing else to configure" currently reads as if the name is held.
1 participant
Summary
Registers the Python SDK for independent releases, mirroring the sdk-typescript registration in #546:
release-please-config.json: newsdk/pythonpackage —release-type: python, componentsdk-python,include-component-in-tag: true(tagssdk-python-vX.Y.Z);sdk/pythonadded to the root package'sexclude-paths..release-please-manifest.json: seeded at the package's current0.1.0.sdk/python/README.md: new Releasing section — the release-please flow, the tag-triggered publish workflow (release-sdk-python.yml, lands separately), and the PyPI pending trusted publisher bootstrap: PyPI lets us pre-register project namearcbox+ repoarcboxlabs/arcbox+ workflow filename before the first upload, so CI does the first publish — no local bootstrap publish, no API token (unlike npm, whose trusted publisher needs an existing package). Also retires the staleUV_PUBLISH_TOKENnote in Toolchain notes.Stacking
Stacked on #547 (
feat/sdk-python) — merge that first.sdk/python(the README this documents, thepyproject.tomlwhose version is seeded) exists only on that branch; #546's tip explicitly backed the Python scaffold out, so stacking there would have documented a package its base does not contain.Overlap with #546 is confined to two adjacent-line insertions in
release-please-config.json/.release-please-manifest.json(both add a component entry); whichever lands second picks up a trivial conflict — resolution is the union.Publish workflow
The matching
.github/workflows/release-sdk-python.yml(tag trigger, tag↔pyproject guard, PyPI idempotency pre-check, uv gates,uv build+uv publishwith OIDC trusted publishing) is parked on a local branch alongside the npm one — workflow files cannot be pushed with this token.