#✨ SDK should not be forced to implement ...
storm folio
uhh, i didn't have time to finish it 😦
i would really love if someone had time to pick it up!
it fixes so many issues lol
hollow oyster
Then I'm your man haha, I have few things to finish on client gen and I'll take care of it
storm folio
yes please ❤️
hollow oyster
I don't know on which interface I should put it though, looks like its its own think, maybe in the base SDK interface since all SDK should implement an init method
storm folio
I don't know on which interface I should put it though, looks like its its own t...
yes it's own interface!
imagine doing dagger init --sdk=magic or something - it might just generate a README or something of how to use it
there's no corresponding codegen in this case
hollow oyster
You're right
storm folio
i'll make a tracking issue for this quickly
hollow oyster
Happy to be tagged on it!
storm folio
thanks 🙏
the only other thing i can think of is i wonder if the "methods called on the engine" still applies - we've changed a lot of how the sdk-calling-convention works, i wonder how much GeneratedContextDirectory still makes sense in this context 🤔
i can't think of anything better, so not sure
last relic
Hey, that's the whole idea behind https://github.com/dagger/dagger/issues/7707.
storm folio
@last relic not convinced it's a full duplicate, but fair 🙂 i think the table breakdown is useful, if it is a duplicate, we should make sure it's in 7707
last relic
Yeah, discussion should be moved there.
last relic
<@768585883120173076> not convinced it's a full duplicate, but fair 🙂 i think t...
What do you think differs from this new issue?
storm folio
imo, i think i've been thinking of 7707 as an "epic" issue - @hollow oyster has been working on it piece by piece, latest step being the break up in core/sdk.go. i think the new issue is just the next step in that process (maybe the last one?)
i dunno feel like 7707 also is about the usability of building sdks, etc, but maybe that's me confusing bits up
last relic
imo, i think i've been thinking of 7707 as an "epic" issue - <@28187448065182925...
I don't see it like that. The point of 7707 is instead of having an "sdk" interface where the "runtime module" (aka "sdk module") has to implement both ModuleRuntime and Codegen, the "sdk module" would instead support different features based on the functions that it defines. So if it has a ModuleRuntime then it supports executing a module. If it has Codegen, it supports generating client bindings. As a part of this, it's a recurring theme that Codegen needed to be split into just client bindings, and module specific generation (two functions). Tom created the former. The idea is that the "module generation" is backed by the client bindings generation.
In 7707 Solomon asks for a discussion. I think the table is great but that's exactly the sort of thing that should be continuing the discussion in 7707.
storm folio
sure sgtm
hollow oyster
So I should close my issue and copy paste the comment on 7707?
storm folio
doesn't really matter to me where we have the discussion, as long as we're having it
storm folio
So I should close my issue and copy paste the comment on 7707?
that's probably best 😄
hollow oyster
Alright
last relic
So I should close my issue and copy paste the comment on 7707?
I already marked it as duplicate, I suggest you make your design proposal there. When there's consensus you can update the description of the issue with the agreed design, table included. You're already assigned to 7707.
hollow oyster
Alright