Publish codex app-server Python SDK core and bundled packages#14648
Publish codex app-server Python SDK core and bundled packages#14648
Conversation
![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: c9230a345d
ℹ️ 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".
.github/workflows/rust-release.yml
Outdated
| pattern: python-runtime-* | ||
| path: dist-pypi/runtime | ||
| merge-multiple: true |
There was a problem hiding this comment.
publish-pypi-runtime downloads all python-runtime-* artifacts into one folder with merge-multiple: true. The workflow now builds runtime wheels for both *-linux-gnu and *-linux-musl targets of the same arch; these produce the same wheel filename/tag, so one file can silently overwrite the other. That makes the published Linux runtime wheel nondeterministic and may ship the wrong binary variant.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
codex -> codex:
Good catch. That was a real issue.
codex-cli-bin currently relies on inferred wheel tags, so the GNU and musl Linux builds for the same arch can produce the same wheel filename. With merge-multiple: true, one runtime wheel could overwrite the other before publish.
I pushed a fix that makes publish-pypi-runtime download only the runtime wheels we want to publish to PyPI today: macOS, Windows, and GNU Linux. Musl runtime wheels are still built as release artifacts, but they are no longer uploaded to PyPI until we have a packaging story that gives GNU and musl distinct wheel tags.
sdcoffey
force-pushed
the
dev/steve/python-sdk-core-release
branch
from
3d881fb to
65640e2
Compare
There was a problem hiding this comment.
probably out of scope for what this PR is trying to do, but should we integrate https://github.com/facebook/dotslash somehow?
|
I think that would be good! but the proximate goal i had in mind is for public consumption–we're going to be consuming it outside the monorepo, and i'm sure others will want to as well |
| name: pypi | ||
|
|
||
| steps: | ||
| # Do not publish musl runtime wheels to PyPI yet. GNU and musl builds for |
There was a problem hiding this comment.
I think we should drop GNU builds.
|
Closing this pull request because it has had no updates for more than 14 days. If you plan to continue working on it, feel free to reopen or open a new PR. |
4 participants
Summary
codex-app-server-sdk-corepackage and a bundledcodex-app-server-sdkmetapackagecodex-cli-bin,codex-app-server-sdk-core, andcodex-app-server-sdkto PyPI in dependency orderWhy
We need downstream SDKs to be able to depend on the app-server Python surface without transitively pulling down platform binaries.
Python packaging does not give downstream consumers a clean way to suppress a required dependency from a transitive package. If
codex-app-server-sdkdirectly depends oncodex-cli-bin, then any SDK depending on it also pulls in the binary package.That means the package with the real Python code needs to be the runtime-free one, and the bundled install experience needs to be layered on top.
Package breakdown
codex-app-server-sdk-core: the actual Python SDK code. It ships thecodex_app_servermodule and has no dependency oncodex-cli-bin. This is the package downstream SDKs should depend on when they want to provide their owncodexbinary viaAppServerConfig(codex_bin=...).codex-cli-bin: the platform-specific runtime wheel that carries thecodexbinary.codex-app-server-sdk: a thin convenience metapackage for regular users. It depends on exact matching versions ofcodex-app-server-sdk-coreandcodex-cli-bin, sopip install codex-app-server-sdkstill gives the batteries-included experience.Release flow
A
rust-vX.Y.Ztag now drives all three Python artifacts at the same version:codex-cli-binwheels for each release platformcodex-app-server-sdk-corecodex-app-server-sdklast, after its dependencies are availableThis keeps the default install path simple for end users while giving downstream SDK authors a supported no-binary dependency surface.