Prepare Python SDK for CLI 1.0 init contract#2
Open
eunomie wants to merge 2 commits into
Open
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>
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
1 participant
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.