Add native Python SDK configuration (python version, uv, base image)

[eunomie]

Make Python module customization first-class in the python-sdk module, instead of requiring users to hand-edit pyproject.toml. Three settings are exposed: Python version, uv vs pip, and base image — both at creation time (via init flags) and afterward (via mod ... config commands). All settings persist to the module's pyproject.toml.

Configure at creation

dagger call python-sdk init --name my-module \
    --python-version 3.13 \
    --use-uv=false \
    --base-image python:3.13-slim

All flags are optional. Defaults leave the template untouched (template Python version, uv enabled, no base image override).

Configure an existing module

mod ... config exposes two functions: get and set.

Read the current configuration. Settings not explicitly written to pyproject.toml are reported as null rather than guessed:

dagger call python-sdk mod --path my-module config get

Select a single value:

dagger call python-sdk mod --path my-module config get python-version
dagger call python-sdk mod --path my-module config get use-uv
dagger call python-sdk mod --path my-module config get base-image

Change one or more values at once (returns a Changeset, prompting before writing). Each flag is optional; omitting one leaves that setting untouched:

dagger call python-sdk mod --path my-module config set \
    --python-version 3.13 \
    --use-uv=false \
    --base-image python:3.13-slim

Where it's stored

Setting	Location in pyproject.toml
Python version	[project].requires-python = ">=X.Y"
uv vs pip	[tool.dagger].use-uv (written only when false; absent ⇒ uv)
Base image	[tool.dagger].base-image (absent ⇒ SDK default)

How it works

A small TOML-aware Go helper (helpers/pyproject) reads/edits pyproject.toml, preserving unrelated keys and pruning empty tables. Both the init flags and the mod.config command surface drive that single helper, so there is one source of truth for reading and writing config.

Reads never guess: an absent use-uv is reported as unset rather than defaulting to true, so config get distinguishes "not configured" from an explicit choice.

Testing

• Go unit tests for the helper (helpers/pyproject).
• e2e checks configCheck and initConfigCheck cover config get (including unset-reported-as-null), config set (multi-value and partial/leave-untouched), single-file-scope edits, and init flag output.

[TomChv]

Early approval, is that expected though if the module does not load?

[kpenfound]

@TomChv if you're referring to the ci checks, yeah I think its expected that it only loads with the workspace build and not 0.21.0