Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: dagger/python-sdk
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: dagger/python-sdk
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: as-sdk-discovery
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 3 commits
  • 3 files changed
  • 2 contributors

Commits on Jun 19, 2026

  1. feat: discover managed modules via CurrentModule.asSDK

    generateAll discovered modules by scanning the workspace for legacy
    dagger.json files with sdk.source "python". cli-1.0 workspace modules use
    dagger-module.toml and are tracked in [[modules.<sdk>.as-sdk.modules]], so
    that scan finds nothing and generate-all returns an empty changeset.
    
    Discover managed modules from the engine's source of truth instead, via
    currentModule.asSDK.modules.
    
    Signed-off-by: Yves Brissaud <yves@dagger.io>
    eunomie committed Jun 19, 2026
    Configuration menu
    Copy the full SHA
    336e528 View commit details
    Browse the repository at this point in the history

Commits on Jun 20, 2026

  1. chore: run SDK module on CLI 1.0 schema

    Problem:
    generateAll now reads currentModule.asSDK.modules. That field is part of the
    CLI 1.0 schema view, so this SDK module has to load with a v1 engine contract.
    Leaving the module on the v0.21 schema makes the new discovery path fail before
    the generator logic can run.
    
    Change:
    - set engineVersion to v1.0.0-0
    - pin polyfill to the sdk-sdk commit that handles dagger-module.toml
    - update Dang field projections to the v1 syntax
    
    This does not change what generated Python modules contain. It makes the SDK
    helper module load against the schema it now uses.
    
    Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
    grouville committed Jun 20, 2026
    Configuration menu
    Copy the full SHA
    71699bb View commit details
    Browse the repository at this point in the history
  2. test(e2e): install local SDK as an SDK

    Problem:
    The e2e workspace only loaded the e2e module. That was enough while generateAll
    scanned dagger.json files, but it no longer matches the CLI 1.0 contract.
    generateAll now reads currentModule.asSDK.modules, which only exists when the
    SDK module is installed in the workspace with an as-sdk entry.
    
    Change:
    Install the local Python SDK module in dagger.toml and list the fixture modules
    it manages. That makes the e2e workspace look like the user-facing flow after
    `dagger sdk install python`: the SDK owns a set of modules recorded under
    [[modules.python-sdk.as-sdk.modules]].
    
    The SDK root also exposes @generate functions. Unqualified `dagger check` treats
    those generators as checks and would fail because python-sdk:generate-all
    produces fixture changes. Add check.skip = ["*"] on the SDK root entry so the
    repo's default check runs the e2e checks without treating the SDK helper's own
    generators as repo checks. The e2e module still calls generateAll directly, so
    coverage for the new discovery path remains.
    
    Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
    grouville committed Jun 20, 2026
    Configuration menu
    Copy the full SHA
    cf82ee7 View commit details
    Browse the repository at this point in the history
Loading