{{ message }}
Prepare Python SDK for CLI 1.0 init contract#2
Merged
Conversation
Mirror the Go SDK's CLI 1.0 init-contract preparation (dagger/go-sdk#2) for the Python SDK: - add `targetRuntime` returning "python" so modules initialized through this SDK target the built-in Python runtime - replace `init` with `initModule(ws, name, path, template, pythonVersion, useUv, baseImage)` that returns only the Python-owned template files; the engine owns dagger.json / dagger-module.toml and workspace config and merges this changeset with its own bookkeeping - remove the SDK-owned `mod deps` / `mod engine` command surfaces, now owned by the core CLI (`dagger module deps` / `dagger module engine`) - mark the `modules` / `generate-all` discovery path as legacy dagger.json discovery, obsolete for workspace-managed modules - update the e2e checks and README to match The Python build-config surface (`mod config`) stays in this module, as it is genuinely SDK-specific. `initClient` is intentionally out of scope: generating a Python client is a code-generator concern, mirroring the Go SDK which stays module-only. Signed-off-by: Yves Brissaud <yves@dagger.io>
Signed-off-by: Yves Brissaud <yves.brissaud@gmail.com>
grouville
added a commit
that referenced
this pull request
Jun 18, 2026
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. 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
added a commit
that referenced
this pull request
Jun 18, 2026
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>
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>
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>
tiborvass
approved these changes
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Mirrors the Go SDK's CLI 1.0 init-contract preparation (dagger/go-sdk#2) for the Python SDK.
targetRuntimereturningpythonso modules initialized through this SDK target the built-in Python runtime (consumed by the engine'sRuntimeTargetwiring ondesign/cli-1.0)initcommand withinitModule(ws, name, path, template, pythonVersion, useUv, baseImage)that returns only the Python-owned template files. The engine owns the module config (dagger-module.toml) and workspace config, and merges this changeset with its own bookkeeping. Dropped from the SDK: writingdagger.json, path-defaulting against the nearest.dagger, the "module already exists" guard, andignoreGenerated— all now engine concerns.mod deps/mod enginesurfaces (mod-deps.dang,mod-engine.dang, and theMod.deps/Mod.engineaccessors). These are identical across SDKs and are now owned by the core CLI (dagger module deps/dagger module engine).modules/generate-alldiscovery path as legacydagger.jsondiscovery — obsolete for workspace-managed modules, where the engine owns themodules.<sdk>.as-sdk.modulessource of truth.Scope notes
mod config, i.e.pyproject.tomlediting) stays in this module — it is genuinely Python-specific and belongs to the SDK (reachable viadagger module sdkin the new CLI).initClientis intentionally not added. Generating a Python client is a code-generator concern; this keeps Python module-only for now, mirroring the Go SDK.pythonVersion,useUv,baseImage,template) are preserved oninitModuleso the CLI surfaces them as typed flags ondagger module init python.Changes to tests / docs
e2e/main.dang:initCheck/initConfigCheckupdated forinitModule(nodagger.json, noignoreGenerated); removedengineVersionCheck,dependencyListCheck,dependencyEditCheck(surface moved to core CLI); added atargetRuntimeCheck.README.md: documents thedagger module init pythonflow, points deps/engine at the core CLI, keeps the config section, and notes the legacy discovery path.Validation
Not run locally (no engine in this environment) — relies on CI to exercise the
@checke2e suite. The Dang sources were edited to preserve existing style; please verify the checks pass.