So I've been experimenting with custom

[silver venture]

I don't think that would be a huge lift in terms of implementation. Loading and calling a module function goes through the ModuleSource API, which already has a withSDK field to support setting the SDK (during init, develop, etc.)

But it would all work if you just dynamically set the SDK every time.

Obviously SDK != runtime exactly, but close enough that this would all work fairly seamlessly with some minor adjustments

If you wanted to play around with this today, you could just use the module source API from shell

[wispy bluff]

Nice thank you!

Separately I've been wondering about how we could spin out the "runtime API" from the "SDK API", the same way @upper elk started with the client generator. I love the idea of decoupling, and it feels weird that I have to implement a no-op codegen function. BUT, I don't want to overcomplicate the UX with more concepts, breaking changes etc.

[grim peak]

Yeah that's planned, at least in my book, as part of https://github.com/dagger/dagger/issues/7707. It's related to what Tom is already doing so should be a trivial change after the CLI is adapted to leverage different features based on what's implemented in the SDK module.

[upper elk]

https://github.com/dagger/dagger/pull/10309 is already splitting the SDK interface, now we need to update the CLI + engine core to not call a function if it's not implemented and not required

Dagger call -> Only needs runtime
Dagger develop -> Only needs Codegen OR Generated client

So you wouldn't need to implement Codegen if you don't need to for your custom runtime but that means we should throw an error if you call dagger develop, to say that the SDK of that module doesn't have the capability to generate code (or we can silently do nothing).

This shouldn't be a breaking change, just a better UX

I'll do that next week, it's on my list of todos 😄

[wispy bluff]

Thanks guys - yeah to be clear, for that part (the decoupling of runtime from SDK) I'm not worried about feasibility or implementation difficulty, but mostly UX. How to design this change so that it's a better experience overall, and the transition itself is not painful

[upper elk]

Normally the user shouldn't notice anything, except when he will implements / use a custom runtime and find out that he doesn't need to implement the whole interface to make it work

[wispy bluff]

A few examples of what I mean:

• dagger init --sdk --> do we add --runtime? Does it deprecated --sdk or do we keep both? If we keep both, how do we explain when to use which

• How do we explain in the docs the relationship between a SDK and a runtime. The Go, Typescript, Python SDKs have a runtime. What do we call that runtime. Does it have a docs area of its own? etc

[upper elk]

I see

[wispy bluff]

dagger.json has a field sdk. Should it have a field runtime? Same questions around replacing vs. co-existing e

[upper elk]

I think sdk is fine as it is no?

a SDK can implement 1 or multiple component of the SDK interface, codegen, runtime, client generator, but it's still an SDK no?