Self calls support in SDKs | Dagger | Page 1

sterile steeple Jul 23, 2025, 1:22 PM

#

Hey @remote valley 👋 Is this PR already implementing self calls?
https://github.com/dagger/dagger/pull/10584

GitHub

SDK: add `moduleTypeDefs` to module SDK, to register type definitio...

NoteThis has been extracted and cleaned from #10475
This is a first step to #10336 and #8030

This PR introduces a new moduleTypeDefs method modules can implement. This method acts like moduleRunti...

#

Where do I begin to add support for Python?

remote valley Jul 23, 2025, 1:26 PM

#

Yes it's this one. The description is not up to date, I'll fix that soon. I changed the way it works while I was doing it, so some parts still need a bit cleaning.

#

I'm fixing one last bug that might impact all SDKs except Go...

#

Basically what needs to be done is for python SDK to declare a moduleTypeDefs function:

func (m *JavaSdk) ModuleTypeDefs(
    ctx context.Context,
    modSource *dagger.ModuleSource,
    introspectionJSON *dagger.File,
) (*dagger.Module, error)

This function should return a module, the equivalent of the "register" side of the actual entrypoint

#

And for that there's the possibility to use dag.Module().FromJSON function. The JSON might not be final and we can improve some parts (especially case) but I focused on having something working first

sterile steeple Jul 23, 2025, 1:38 PM

#

Ok, how have you solved for Go? If an SDK doesn't implement ModuleTypeDefs, does the engine try to get them from ModuleRuntime?

sterile steeple Jul 23, 2025, 1:40 PM

#

remote valley Basically what needs to be done is for python SDK to declare a `moduleTypeDefs` ...

That's just to split type registration with invocation, right? What would I need to do next?

remote valley Jul 23, 2025, 1:41 PM

#

if there's no moduleTypeDefs then it just use the moduleRuntime yes, and call it with an empty function name to get the types

#

that's the only needed aspect, to split the registration. The rest is automatically handled

sterile steeple Jul 23, 2025, 1:45 PM

#

That's pretty great! So you get the typedefs early on, then expand the schema, send the introspection json to the SDK's codegen which should include the own module's types already?

#

What if moduleTypeDefs needs codegen?

#

Maybe not an issue since referencing other modules can't be in signatures, only function bodies?

remote valley Jul 23, 2025, 1:58 PM

#

for SDKs other than go, yes they might need codegen first. Just to build the Dagger types to be able to answer the moduleTypeDefs. It's not mandatory, but that's how it's done for the Java SDK.
That's why moduleTypeDefs also taks an introspection JSON file. With it, the module can generate the required types. Then the moduleRuntime will receive a different json, enhanced with the types exposed

#

Definitely if we can avoid it it's better, quicker, but it's really SDK dependent

sterile steeple Jul 23, 2025, 2:05 PM

#

How does that work in Java? You need codegen in order to introspect the code, but at this first run you won't have self calls yet, so what's the difference between a function referencing a dependency or a self call in terms of being able to compile and run?

remote valley Jul 23, 2025, 2:26 PM

#

In fact the way the Java SDK is done is the code that is doing the introspection of the module's code requires itself the dagger java sdk as it's the same code that will also generate the entrypoint.
If the Java SDK was published as a dependency I can fetch, or if all the "default" SDK Java files were generated and available in the repository, that would not be necessary.
That's something I'd like to fix, but later.

#

The introspection code doesn't require the code to be buildable, so the fact some types are not generated is not a problem for Java here

sterile steeple Jul 23, 2025, 2:31 PM

#

Then can't you use the core api bindings that are already included in the current engine instead of running codegen first?

sterile steeple Jul 24, 2025, 3:54 PM

#

@remote valley, Python's registration makes a call to dag.current_module().name(), does that work within ModuleTypeDefs?

remote valley Jul 24, 2025, 4:03 PM

#

hum, I'm not sure. I think the type defs doesn't care about the name, the "module" is just a host of the objects and other types, and things like name will not be used

sterile steeple Jul 24, 2025, 4:07 PM

#

Yeah, I use it to validate if the code has a class with the right name.

#

I can pass it on from the sdk module if needed.

remote valley Jul 24, 2025, 5:52 PM

#

I updated to body of the PR to help understand how that's done: https://github.com/dagger/dagger/pull/10584

GitHub

SDK: self invocation by eunomie · Pull Request #10584 · dagger/da...

NoteThis has been extracted and cleaned from #10475
This is a first step to #10336 and #8030

This PR implements the ability for modules to self invoke themselves.
func (m *TestGo) ContainerEcho(st...

sterile steeple Jul 24, 2025, 6:09 PM

#

I made the changes to the Python runtime in the sdk module and to the Python entrypoint, now my dev engine is crashing with this:

time="2025-07-24T17:55:36Z" level=debug msg="installing module" name=python-sdk
time="2025-07-24T17:55:36Z" level=debug msg="installing object" name=python-sdk object=PythonSdk
time="2025-07-24T17:55:36Z" level=debug msg="type is already defined by dependency module" module=python-sdk type=PythonSdk
time="2025-07-24T17:55:36Z" level=debug msg="done installing module" name=python-sdk took="120.833µs"
time="2025-07-24T17:55:36Z" level=debug msg="installing module" name=python-sdk
time="2025-07-24T17:55:36Z" level=debug msg="installing object" name=python-sdk object=PythonSdk
time="2025-07-24T17:55:36Z" level=debug msg="type is already defined by dependency module" module=python-sdk type=PythonSdk

I'm trying to run dagger-dev develop on a new module that I've init'ed with stable engine, just changed the source from "python" to point to the relative path so it's easier to iterate.

remote valley Aug 6, 2025, 1:59 PM

#

I missed this 😕
Does it still happen?
I thought I changed it so that already defined modules don't fail anymore. But thinking again, not sure that's a good idea or not 🤔

#Self calls support in SDKs