Skip to content

python-sdk: add CLI 1.0 client init#4

Merged
tiborvass merged 2 commits into
prepare-cli-1.0-init-contractfrom
codex/cli-1-init-client
Jun 19, 2026
Merged

python-sdk: add CLI 1.0 client init#4
tiborvass merged 2 commits into
prepare-cli-1.0-init-contractfrom
codex/cli-1-init-client

Conversation

@grouville

@grouville grouville commented Jun 18, 2026

Copy link
Copy Markdown
Member

Why

This PR is stacked on #2 (prepare-cli-1.0-init-contract). #2 carries the Python SDK module init contract work. This PR keeps the next piece narrow: add the CLI 1.0 initClient hook that the engine calls when a workspace adds a managed client, add e2e coverage for that hook, and load the e2e module through workspace config.

Dogfood workspace checks also exposed that Python still pinned an older sdk-sdk/polyfill. Its helper binaries were built against dagger.io/dagger v0.20.6 and queried loadWorkspaceFromID, which fails against the CLI 1.0 dev engine schema. This PR bumps the polyfill pin/lock to the same commit used by the TypeScript SDK.

What Changed

  1. Add initClient.

    • Signature matches the CLI 1.0 SDK contract, including dev.
    • Implementation returns an empty Changeset.
    • The engine already records managed clients and owns generated client materialization via the generated context changeset.
  2. Add e2e coverage.

    • The e2e module calls pythonSdk.initClient(...).
    • It asserts that the SDK returns an empty changeset.
  3. Load e2e through workspace config.

    • dagger.toml installs only .dagger/modules/e2e as e2e.
    • The Python SDK root module is not added as a workspace module.
    • The e2e module engine pin moves to v0.21.4, matching the TypeScript SDK e2e module.
  4. Refresh the polyfill pin used by workspace helper commands.

    • Bumps sdk-sdk/polyfill from 09da957... to d1532df....
    • Updates .dagger/lock to the same commit.
    • Fixes workspace-module-generate and workspace-snapshot against the CLI 1.0 dev engine schema.

What This Does Not Do

This PR does not duplicate the targetRuntime or initModule changes from the stacked base branch. It should be reviewed as the client-init and workspace-load delta on top of #2.

Validation

Run with the local CLI 1.0 dev engine:

/home/dagger/dagger/hack/with-dev dagger --progress=plain session --load-workspace-modules --label dagger.io/sdk.name:go --label dagger.io/sdk.version:n/a
/home/dagger/dagger/hack/with-dev dagger --progress=plain call e-2-e init-client-check
/home/dagger/dagger/hack/with-dev dagger --progress=plain call e-2-e generate-all-check
/home/dagger/dagger/hack/with-dev dagger --progress=plain call e-2-e config-check

@grouville grouville force-pushed the codex/cli-1-init-client branch 2 times, most recently from 40b2c89 to 138976a Compare June 18, 2026 22:36
@grouville grouville changed the title python-sdk: add CLI 1.0 init hooks python-sdk: add CLI 1.0 client init Jun 18, 2026
@grouville grouville changed the base branch from main to prepare-cli-1.0-init-contract June 18, 2026 22:36
@grouville grouville force-pushed the codex/cli-1-init-client branch 2 times, most recently from 907e5ad to 45a493e Compare June 18, 2026 22:57
CLI 1.0 calls initClient when a workspace adds a managed client. The Python
SDK init-contract work lives in the stacked prepare-cli-1.0-init-contract
branch, but that branch does not add the client hook.

Add initClient with the CLI 1.0 signature, including the dev flag. It returns
an empty Changeset on purpose: the engine records the client and owns generated
client files through GeneratedContextChangeset.

Add an e2e check that calls initClient and verifies the SDK returns no file
changes.

This keeps the PR narrowly scoped on top of #2. It only adds the client init
hook and does not duplicate the targetRuntime or initModule changes from the
stacked base.

Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
@grouville grouville force-pushed the codex/cli-1-init-client branch from 45a493e to 6905b24 Compare June 18, 2026 23:01
Dogfood load checks run through workspace modules. The Python SDK repo did not have a dagger.toml, so CI was not loading its in-repo e2e module through the same workspace path as the Go and TypeScript SDK repos.

Add a minimal dagger.toml that includes only .dagger/modules/e2e. The Python SDK root module is intentionally not listed as a workspace module; it remains the root module that the e2e module depends on through a local source.

The workspace e2e checks call sdk-sdk/polyfill helper binaries such as workspace-module-generate and workspace-snapshot. The old Python SDK pin built those helpers against dagger.io/dagger v0.20.6, which still queried loadWorkspaceFromID and fails against the CLI 1.0 dev engine schema. Bump the polyfill pin and lock to the same commit used by the TypeScript SDK, where those helpers are compatible with the current workspace API.

Also bump the e2e module engine pin to v0.21.4 so the workspace-loaded test module runs with the same schema generation baseline as the TypeScript SDK e2e module.

Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
@grouville grouville force-pushed the codex/cli-1-init-client branch from 6905b24 to db199ca Compare June 18, 2026 23:16
@tiborvass tiborvass merged commit 7bf689c into prepare-cli-1.0-init-contract Jun 19, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants