feat: ship a useful default Python init template

[grouville]

Why

Today, dagger module init python hello creates a valid module whose object only contains pass. It works, but it does not show a new user how to turn their workspace into something useful.

For the 1.0 experience tracked in dagger/dagger#13626, the default should be a small working example. This follows the direction established by dagger/typescript-sdk#10.

What changes

The new default stores a filtered view of the caller's workspace and exposes a container function with that source mounted at /src. It uses Alpine 3.24 by default, while keeping the image configurable.

The template stays deliberately generic: it does not assume the workspace is a Python project, uses uv, or has a particular build command. uv is only used to package the generated Dagger module.

The previous blank template is now available as --template empty. legacy is unchanged, and an explicitly empty template value continues to select the default for compatibility.

The generated project files also move to Python 3.14 and accept uv_build releases below 0.12. The lower bound remains compatible with the uv version already bundled in the engine.

Why create instead of __init__

The template uses the Python SDK's supported alternate create constructor. It receives the caller's workspace and converts it into the fields Dagger stores between function calls. This keeps the user-facing workspace input separate from the state Dagger needs to restore later.

Try it

From an empty Git repository:

dagger sdk install github.com/grouville/python-sdk@feat/default-template --name python -y
dagger module init python hello -y
dagger api functions hello
dagger api call hello container \
  with-exec --args sh --args -c --args 'test -f /src/dagger.toml && pwd' \
  stdout

dagger api functions hello should list container, and the final command should print /src.

To check the blank template:

dagger module init python blank --template empty -y
sed -n '1,20p' .dagger/modules/blank/src/blank/__init__.py

The generated Blank class should contain only pass.

Verification

dagger check e-2-e:template-check
dagger check

All 12 checks pass against v1.0.0-beta.7 and the locally rebuilt engine from dagger/dagger@7a6730c178228b4a3a8273664d319578892b7fe1. A fresh generated module also returned Alpine 3.24.1 when invoked with the beta.7 CLI.

[TomChv]

LGTM, just left a small comment about create but it's mergeable as it is :)

[TomChv]

Are users familiar with this notation? I saw your comment on the PR description about it but if that's confusing for users maybe it's better to use __init__? Or maybe explain it in the README.md
Can't you have the workspace in the constructor with __init__?

[eunomie]

I think that looks good to me.

kMy only concern with the template is if you just discover dagger it might be a bit rough to only get a container, not sure you know what to do with it. Maybe 1 single function that exposes something should be nice. I don't have super nice ideas, but that could be for instance just to output the entries of the source directory. It's not that useful but 🤷

But it also depends on the goal of the template. My remark is about a user not knowing a lot about dagger. But if I know about dagger, and just want to bootstrap a new module, then that feels good as it's very often you want to have a container with the source dir mounted. So feel free to ignore my first remark :-)

As a follow up (so not preventing at all to merge it, just FYI) I'll look into simplifying the directory structure when we create a new python module. It will have a small impact on the output of an init, but not on the content of the template.