[1/8] Pin Python SDK runtime dependency#21891
Conversation
|
This change is part of the following stack:
Change managed by git-spice. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41a3b1da7e
ℹ️ 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".
| "Topic :: Software Development :: Libraries :: Python Modules", | ||
| ] | ||
| dependencies = ["pydantic>=2.12"] | ||
| dependencies = ["pydantic>=2.12", "openai-codex-cli-bin==0.131.0a4"] |
There was a problem hiding this comment.
Publish Linux runtime wheels pip can install
Pinning this dependency makes every SDK install resolve openai-codex-cli-bin, but the new lockfile only has Linux wheels tagged musllinux_1_1_*. Standard glibc Linux interpreters advertise manylinux/linux tags, not musllinux, so pip/uv install openai-codex-app-server-sdk will fail on the common Linux target until manylinux/linux-compatible runtime wheels are published or the dependency is conditional.
Useful? React with 👍 / 👎.
6679dff to
edf326e
Compare
edf326e to
c24694b
Compare
## Why Published Python SDK builds depend on an exact `openai-codex-cli-bin` runtime package, but the release workflow did not publish that runtime package to PyPI. That left the SDK packaging story incomplete: release artifacts could produce Codex binaries, but Python users still needed a matching wheel carrying the platform-specific runtime and helper executables. This PR is stacked on #21787 so release jobs can include helper binaries in runtime wheels: Linux wheels include `bwrap` for sandbox fallback, and Windows wheels include the signed sandbox/elevation helpers beside `codex.exe`. ## What changed - Builds platform-specific `openai-codex-cli-bin` wheels from signed release binaries on macOS, Linux, and Windows release runners. - Packages Linux `bwrap` into musllinux runtime wheels. - Packages Windows sandbox helper executables into Windows runtime wheels. - Uploads runtime wheels as GitHub release assets and publishes them to PyPI using trusted publishing from the `pypi` GitHub environment. - Keeps the new Python runtime publish job non-blocking so failures need follow-up but do not fail the Rust release workflow. - Pins the PyPA publish action to the `v1.13.0` commit SHA for reproducible release publishing. - Documents that runtime wheels are platform wheels published through PyPI trusted publishing. ## Testing - `ruby -e 'require "yaml"; ARGV.each { |f| YAML.load_file(f); puts "ok #{f}" }' .github/workflows/rust-release.yml .github/workflows/rust-release-windows.yml` - `git diff --check` CI is the real end-to-end verification for the release workflow path. --------- Co-authored-by: Codex <noreply@openai.com>
Build platform-specific openai-codex-cli-bin wheels from signed release binaries and publish them to PyPI using trusted publishing. Co-authored-by: Codex <noreply@openai.com>
Document why the release workflow includes sandbox helper executables in Windows Python runtime wheels. Co-authored-by: Codex <noreply@openai.com>
Pass the release bwrap binary into Linux runtime wheel staging so PyPI installs preserve sandbox fallback behavior. Co-authored-by: Codex <noreply@openai.com>
Set the Python runtime publish job environment to match the PyPI trusted publisher configuration. Co-authored-by: Codex <noreply@openai.com>
Use the v1.13.0 commit for the PyPI publish action so the pinned action reference has a clear release version. Co-authored-by: Codex <noreply@openai.com>
Allow the Rust release workflow to finish even if the new Python runtime PyPI publish job needs follow-up. Co-authored-by: Codex <noreply@openai.com>
Avoid installing build into runner-managed Python environments when release jobs build runtime wheels. Co-authored-by: Codex <noreply@openai.com>
Build the stage-runtime command as a single non-empty Bash array and append Linux resource binaries conditionally so macOS runners do not expand an empty optional array under set -u. Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Make the Python SDK declare its published runtime package dependency directly and resolve the runtime version from that pin instead of inferring it from the SDK package version. Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
becbd2a to
284b1ee
Compare
c24694b to
cf7e95f
Compare
Why
The Python SDK depends on the app-server runtime package for the bundled
codexbinary and schema source of truth. That relationship should be explicit in package metadata instead of inferred from matching version numbers, so installers, lockfiles, and reviewers can see exactly which runtime the SDK expects.What
openai-codex-cli-bin==0.131.0a4as a Python SDK dependency.Stack
[1/8]Pin Python SDK runtime dependency[2/8]Generate Python SDK types from pinned runtime[3/8]Run Python SDK tests in CI[4/8]Define Python SDK public API surface[5/8]Rename Python SDK package toopenai-codex[6/8]Add high-level Python SDK approval mode[7/8]Add Python SDK app-server integration harness[8/8]Add Python SDK Ruff formattingVerification