[eunomie]

This PR moves the engine release the Python SDK targets by default from v1.0.0-beta.23 to v1.0.0-beta.24, restores Python 3.11 support, and adds boundary tests for the existing check that refuses a targetVersion later than the targeted release.

What changes

python-sdk: target v1.0.0-beta.24

• The default engineTarget in python-sdk.dang and the library's CLI_VERSION move to v1.0.0-beta.24.
• The README names v1.0.0-beta.24 in a note at the top and in its examples. The unit tests and the generated-entrypoint goldens name it too.
• The on-target engine-e2e checks build the engine from the v1.0.0-beta.24 tag commit, b32e84b60b99b68e836408d4318f0818982ea86d. AGENTS.md names the release.
• dagger.lock replaces the engine entry with v1.0.0-beta.24, sha256:3ad2b0b80942bb5044e57c1765710a5fab0b913557b6ab7d7f4e81700ac4da35.
• dagger.lock gains golang:1.27-alpine, sha256:d200d2dd76b03a99b52651fd1325aff7dcd35422c35c01bac56571b0507f3deb. The v1.0.0-beta.24 engine build needs it since dagger/dagger fbbcfeb78a moved to Go 1.27.

python-sdk: support Python 3.11

• sdk/pyproject.toml and sdk/codegen/pyproject.toml require Python 3.11 or later, and the classifiers list 3.11.
• sdk/uv.lock is resolved for 3.11 with uv 0.13.1. It only gains cp311 wheels; no version changes.
• override comes from typing_extensions, an existing dependency, since typing.override is new in 3.12.
• The module Python floor is 3.11. Generation, init and config set still refuse 3.10 and offer v1.2.0.
• The e2e checks generate and run a module on 3.11, and refuse 3.10. The SDK suites run on the floor in ghcr.io/astral-sh/uv:python3.11-alpine, which replaces the 3.12 entry in dagger.lock.

e2e: check targetVersion just above the targeted release

• The refusal of a targetVersion later than the targeted release already exists in targetRefusal. These tests pin its bounds:
  • v1.0.0-beta.24.1 and v1.0.0 are refused as later.
  • v1.0.0-beta.100 is refused as later in each accepted form, and v1.0.0-beta.9 is refused as below the floor. Identifiers compare as numbers, not text.
  • The floor is accepted in each form.
  • dagger module init python --target-version v1.0.0-beta.24.1 fails with the refusal.

What stays

• The engine floor stays at v1.0.0-beta.18.
• The committed core bindings in sdk/src/dagger/client/gen.py stay at the v1.0.0-beta.18 schema.
• The default templates and images stay on Python 3.14.
• Mentions of v1.0.0-beta.22 or earlier that record when a behaviour arrived, or which engine version a helper mirrors, stay as they are.

What was checked

All of these pass.

On this PR's head, c6a47c74:

• target-version-check;
• target-version-cli-check.

On b81dbf9f, which differs from this head only in the shape of the new target-version tests:

• cli-sdk-check;
• python-floor-refusal-check;
• sdk-test-oldest-python-check;
• target-version-check;
• target-version-cli-check.

On 811cc6e8, the target bump before its README note:

• engine-e2e:target-version-on-target-check;
• engine-e2e:target-version-cli-on-target-check.

On ba206f5f, the target bump before its golang:1.27-alpine lock entry:

• engine-e2e:floor-coverage-check;
• target-version-cli-check;
• target-version-check;
• the unit suite, 570 tests.

Without an engine, on Python 3.11.15:

• a clean install of sdk/, and uv sync --locked;
• an import of every dagger module;
• 566 unit tests, all but the slow tests and two tests that provision an engine;
• describe and entrypoint on the default and empty templates, against core generated from the v1.0.0-beta.24 schema;
• ruff at py311, and mypy at 3.11 reporting the same errors as at 3.14;
• the Go tests of helpers/pyproject.

The engine, golang:1.27-alpine and uv:python3.11-alpine digests match their registries' index digests.

Context

• The core GraphQL schema changes between v1.0.0-beta.23 and v1.0.0-beta.24 by two additive optional arguments: Container.withExec(transparentHugePages:) and File.extract(include:, exclude:).
• The 239 commits between the two tags leave unchanged the three engine files the SDK mirrors.
• A module's generated core bindings come from the engine in the targeted release's view, so modules get the new arguments on their next generate.
• A module with no recorded pin moves to the new default on its next generate. A module with a recorded pin keeps it.