Commit Graph

11 Commits

  • fix: prevent fmt from updating Python SDK lockfile (#22505)
    ## Why
    
    `just fmt` should align source formatting without resolving dependencies
    or rewriting lockfiles. The Python SDK formatting steps run through
    `uv`, so differing local `uv` versions could decide the SDK lock was
    stale and mutate `sdk/python/uv.lock` before Ruff ran.
    
    ## What
    
    - Add `--frozen` to both Python SDK `uv run ... ruff` commands in the
    root `fmt` recipe.
    - Update the existing Python SDK artifact workflow guard test so future
    changes keep the formatter recipe non-lock-mutating.
    
    ## Verification
    
    - `uv run --frozen --project ../sdk/python --extra dev pytest
    ../sdk/python/tests/test_artifact_workflow_and_binaries.py -q`
  • [8/8] Add Python SDK Ruff formatting (#22021)
    ## Why
    
    The Python SDK needs the same tight formatter/lint loop as the rest of
    the repo: a safe Ruff autofix pass, Ruff formatting, editor save
    behavior, and CI checks that catch drift. Without that loop, SDK changes
    can land with formatting or import ordering that differs from what
    reviewers and CI expect.
    
    ## What
    
    - Add Ruff configuration to `sdk/python/pyproject.toml`, excluding
    generated protocol code and notebooks from the normal lint/format pass.
    - Update `just fmt` so it still formats Rust and also runs Python SDK
    Ruff autofix and formatting.
    - Add Python SDK CI steps for `ruff check` and `ruff format --check`
    before pytest.
    - Recommend the Ruff VS Code extension and enable Python
    format/fix/organize-on-save so Cmd+S uses the same tooling.
    - Apply the resulting Ruff formatting to SDK Python files, examples, and
    the checked-in generated `v2_all.py` output emitted by the pinned
    generator.
    - Add a guard test for the `just fmt` recipe so it keeps working from
    both Rust and Python SDK working directories.
    
    ## Stack
    
    1. #21891 `[1/8]` Pin Python SDK runtime dependency
    2. #21893 `[2/8]` Generate Python SDK types from pinned runtime
    3. #21895 `[3/8]` Run Python SDK tests in CI
    4. #21896 `[4/8]` Define Python SDK public API surface
    5. #21905 `[5/8]` Rename Python SDK package to `openai-codex`
    6. #21910 `[6/8]` Add high-level Python SDK approval mode
    7. #22014 `[7/8]` Add Python SDK app-server integration harness
    8. This PR `[8/8]` Add Python SDK Ruff formatting
    
    ## Verification
    
    - Added `test_root_fmt_recipe_formats_rust_and_python_sdk` for the
    shared format recipe.
    - Ran `just fmt` after the recipe update.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • [5/8] Rename Python SDK package to openai-codex (#21905)
    ## Why
    
    The SDK should publish under the reserved public distribution name
    `openai-codex`, and its import module should match that name in the
    Python style. Since package names can contain hyphens but import modules
    cannot, the public import path becomes `openai_codex`.
    
    Keeping the rename separate from the public API surface change makes the
    naming change easy to review and avoids mixing it with API curation.
    
    ## What
    
    - Rename the SDK distribution from `openai-codex-app-server-sdk` to
    `openai-codex`.
    - Rename the import package from `codex_app_server` to `openai_codex`.
    - Keep the runtime wheel as the separate `openai-codex-cli-bin`
    dependency.
    - Update docs, examples, notebooks, artifact scripts, lockfile metadata,
    and tests for the new distribution/module names.
    
    ## Stack
    
    1. #21891 `[1/8]` Pin Python SDK runtime dependency
    2. #21893 `[2/8]` Generate Python SDK types from pinned runtime
    3. #21895 `[3/8]` Run Python SDK tests in CI
    4. #21896 `[4/8]` Define Python SDK public API surface
    5. This PR `[5/8]` Rename Python SDK package to `openai-codex`
    6. #21910 `[6/8]` Add high-level Python SDK approval mode
    7. #22014 `[7/8]` Add Python SDK app-server integration harness
    8. #22021 `[8/8]` Add Python SDK Ruff formatting
    
    ## Verification
    
    - Updated package metadata and public API tests to assert the
    distribution and import names.
    
    Co-authored-by: Codex <noreply@openai.com>
  • [2/8] Generate Python SDK types from pinned runtime (#21893)
    ## Why
    
    Once the SDK declares its runtime package, generated Python artifacts
    should come from that pinned runtime rather than whatever app-server
    schema happens to be in the current checkout. That keeps the generated
    API and model surface aligned with the runtime users install.
    
    ## What
    
    - Teach `scripts/update_sdk_artifacts.py generate-types` to invoke the
    pinned runtime package for schema generation.
    - Regenerate `v2_all.py`, `notification_registry.py`, and generated
    public wrapper methods from that schema.
    - Add freshness coverage so regenerating from the pinned runtime must
    leave checked-in artifacts unchanged.
    
    ## Stack
    
    1. #21891 `[1/8]` Pin Python SDK runtime dependency
    2. This PR `[2/8]` Generate Python SDK types from pinned runtime
    3. #21895 `[3/8]` Run Python SDK tests in CI
    4. #21896 `[4/8]` Define Python SDK public API surface
    5. #21905 `[5/8]` Rename Python SDK package to `openai-codex`
    6. #21910 `[6/8]` Add high-level Python SDK approval mode
    7. #22014 `[7/8]` Add Python SDK app-server integration harness
    8. #22021 `[8/8]` Add Python SDK Ruff formatting
    
    ## Verification
    
    - Added `test_generated_files_are_up_to_date` for pinned-runtime
    generation drift.
    - Added generator-structure tests for schema annotation and notification
    metadata generation.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • [1/8] Pin Python SDK runtime dependency (#21891)
    ## Why
    
    The Python SDK depends on the app-server runtime package for the bundled
    `codex` binary 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
    
    - Declare `openai-codex-cli-bin==0.131.0a4` as a Python SDK dependency.
    - Update runtime setup helpers to resolve the runtime version from the
    declared dependency pin.
    - Refresh the SDK lockfile for the pinned runtime wheel.
    - Update package/runtime tests and docs that describe where the runtime
    version comes from.
    
    ## Stack
    
    1. This PR `[1/8]` Pin Python SDK runtime dependency
    2. #21893 `[2/8]` Generate Python SDK types from pinned runtime
    3. #21895 `[3/8]` Run Python SDK tests in CI
    4. #21896 `[4/8]` Define Python SDK public API surface
    5. #21905 `[5/8]` Rename Python SDK package to `openai-codex`
    6. #21910 `[6/8]` Add high-level Python SDK approval mode
    7. #22014 `[7/8]` Add Python SDK app-server integration harness
    8. #22021 `[8/8]` Add Python SDK Ruff formatting
    
    ## Verification
    
    - Added coverage for the SDK runtime dependency pin and runtime
    distribution naming.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Support resource binaries in Python runtime staging (#21787)
    ## Why
    
    Some Codex runtime distributions need helper executables beside the main
    bundled binary. Linux sandbox fallback needs a packaged `bwrap` when no
    suitable system `bwrap` is available, and Windows sandbox/elevation
    needs helper executables discoverable beside `codex.exe`. The checked-in
    `openai-codex-cli-bin` template already packages everything under
    `codex_cli_bin/bin/**`, but the staging script only copied the main
    Codex binary into that directory.
    
    This PR adds the generic staging primitive needed by release workflows
    to build complete platform runtime wheels without baking
    platform-specific helper names into the package template.
    
    ## What changed
    
    - Added repeatable `stage-runtime --resource-binary` support so release
    workflows can copy extra executables beside the bundled Codex binary.
    - Kept resource selection in workflow code, where the platform target is
    known.
    - Added tests that verify resource binaries are copied into the staged
    runtime package, that the wheel include config covers them, and that the
    CLI forwards repeated `--resource-binary` values.
    
    ## Testing
    
    - `uv run ruff check scripts/update_sdk_artifacts.py
    tests/test_artifact_workflow_and_binaries.py`
    - `uv run --extra dev pytest
    tests/test_artifact_workflow_and_binaries.py::test_stage_runtime_release_copies_resource_binaries
    tests/test_artifact_workflow_and_binaries.py::test_runtime_resource_binaries_are_included_by_wheel_config
    tests/test_artifact_workflow_and_binaries.py::test_stage_runtime_stages_binary_without_type_generation`
    
    Full `tests/test_artifact_workflow_and_binaries.py` still has unrelated
    schema-normalization drift in the local checkout.
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Publish Python SDK with Codex-pinned versioning (#18996)
    **note**: a large chunk of this diff comes from regenerating Python
    types after app-server schema changes on `main`.
    
    This is PR 3 of 3 for the Python SDK PyPI publishing split. PR #18862
    refreshed the generated SDK surface, and PR #18865 made the runtime
    package publishable as `openai-codex-cli-bin`; this final PR makes the
    SDK package publishable as `openai-codex-app-server-sdk` and pins both
    packages to the same Codex runtime version.
    
    The key idea is that the published SDK version is the Codex runtime
    version. That one version now drives the SDK package version, the exact
    runtime dependency, the client version reported by the SDK, and the
    bootstrap runtime pin. This keeps release-time versioning in one lane
    instead of scattering checked-in literals through the package.
    
    ## What changed
    
    - Rename the SDK distribution from `codex-app-server-sdk` to
    `openai-codex-app-server-sdk` for conflict-free PyPI publishing.
    - Use `stage-sdk --codex-version ...` with one Codex version for both
    the SDK package version and exact `openai-codex-cli-bin` dependency.
    - Preserve hidden legacy `--runtime-version` / `--sdk-version` args only
    to reject mismatched versions during staging.
    - Map PEP 440 package versions back to Codex release tags for runtime
    setup downloads, e.g. `0.116.0a1` -> `rust-v0.116.0-alpha.1`.
    - Derive `codex_app_server.__version__`, the default
    `AppServerConfig.client_version`, and
    `_runtime_setup.pinned_runtime_version()` from the SDK package/project
    version instead of hardcoding duplicate version strings.
    - Carry the current generated SDK refresh from `main` so
    `generate-types` stays clean after recent app-server schema changes.
    - Update `sdk/python/uv.lock` for the renamed editable package.
    
    ## Validation
    
    - `uv run --extra dev pytest` in `sdk/python` -> 59 passed, 37 skipped.
    - Targeted `uv run ruff check` for the touched SDK files.
    - `git diff --check`.
    - Staged runtime with `--codex-version rust-v0.116.0-alpha.1
    --platform-tag macosx_11_0_arm64`.
    - Staged SDK with `--codex-version rust-v0.116.0-alpha.1`.
    - Built runtime wheel, SDK wheel, and SDK sdist.
    - `twine check /tmp/codex-python-pr3-build/dist/*` -> passed.
    - Clean venv smoke installed `openai-codex-app-server-sdk==0.116.0a1`
    from local dist and pulled `openai-codex-cli-bin==0.116.0a1`.
    - Smoke imports passed for `Codex` and `bundled_codex_path()`.
  • Stage publishable Python runtime wheels (#18865)
    This is PR 2 of the Python SDK PyPI publishing split. [PR
    1](https://github.com/openai/codex/pull/18862) refreshed the generated
    SDK bindings; this PR makes the runtime package itself publishable, and
    PR 3 will wire the SDK package/version pinning to this runtime package.
    
    ## Summary
    - Rename the runtime distribution to `openai-codex-cli-bin` while
    keeping the import package as `codex_cli_bin`.
    - Make the runtime package wheel-only and build `py3-none-<platform>`
    wheels instead of interpreter-specific wheels.
    - Add `stage-runtime --codex-version` and `--platform-tag` so release
    staging can produce the platform wheel matrix from Codex release tags.
    - Add focused artifact workflow tests for version normalization,
    platform tag injection, and runtime wheel metadata.
    
    ## Why Rename
    There is already an unofficial PyPI package,
    [`codex-bin`](https://pypi.org/project/codex-bin/), distributing OpenAI
    Codex binaries. Publishing the official SDK runtime dependency as
    `openai-codex-cli-bin` makes the ownership clear, avoids confusing the
    SDK-pinned runtime wheel with that unowned wrapper, and keeps the import
    package unchanged as `codex_cli_bin`.
    
    ## Tests
    - `uv run --extra dev pytest
    tests/test_artifact_workflow_and_binaries.py` -> 21 passed
    - `uv run --extra dev python scripts/update_sdk_artifacts.py
    stage-runtime /tmp/codex-python-pr2-rebased/runtime-stage
    /tmp/codex-python-pr2-rebased/codex --codex-version
    rust-v0.116.0-alpha.1 --platform-tag macosx_11_0_arm64`
    - `uv run --with build --extra dev python -m build --wheel
    /tmp/codex-python-pr2-rebased/runtime-stage`
    - `uv run --with twine --extra dev twine check
    /tmp/codex-python-pr2-rebased/runtime-stage/dist/openai_codex_cli_bin-0.116.0a1-py3-none-macosx_11_0_arm64.whl`
    
    ## Note
    - Full `uv run --extra dev pytest` currently fails because regenerating
    from schemas already on `main` adds new DeviceKey Python types. I left
    that generated catch-up out of this runtime-only PR.
  • Add Python SDK public API and examples (#14446)
    ## TL;DR
    WIP esp the examples
    
    Thin the Python SDK public surface so the wrapper layer returns
    canonical app-server generated models directly.
    
    - keeps `Codex` / `AsyncCodex` / `Thread` / `Turn` and input helpers,
    but removes alias-only type layers and custom result models
    - `metadata` now returns `InitializeResponse` and `run()` returns the
    generated app-server `Turn`
    - updates docs, examples, notebook, and tests to use canonical generated
    types and regenerates `v2_all.py` against current schema
    - keeps the pinned runtime-package integration flow and real integration
    coverage
    
      ## Validation
      - `PYTHONPATH=sdk/python/src python3 -m pytest sdk/python/tests`
    - `GH_TOKEN="$(gh auth token)" RUN_REAL_CODEX_TESTS=1
    PYTHONPATH=sdk/python/src python3 -m pytest sdk/python/tests -rs`
    
    ---------
    
    Co-authored-by: Codex <noreply@openai.com>
  • Refresh Python SDK generated types (#14646)
    ## Summary
    - regenerate `sdk/python` protocol-derived artifacts on latest
    `origin/main`
    - update `notification_registry.py` to match the regenerated
    notification set
    - fix the stale SDK test expectation for `GranularAskForApproval`
    
    ## Validation
    - `cd sdk/python && python scripts/update_sdk_artifacts.py
    generate-types`
    - `cd sdk/python && python -m pytest`
  • Add Python app-server SDK (#14435)
    ## TL;DR
    Bring the Python app-server SDK from `main-with-prs-13953-and-14232`
    onto current `main` as a standalone SDK-only PR.
    
    - adds the new `sdk/python` and `sdk/python-runtime` package trees
    - keeps the scope to the SDK payload only, without the unrelated
    branch-history or workflow changes from the source branch
    - regenerates `sdk/python/src/codex_app_server/generated/v2_all.py`
    against current `main` schema so the extracted SDK matches today's
    protocol definitions
    
    ## Validation
    - `PYTHONPATH=sdk/python/src python3 -m pytest sdk/python/tests`
    
    Co-authored-by: Codex <noreply@openai.com>