#Erik Sipsma3294 correct me if I m wrong
1 messages ยท Page 1 of 1 (latest)
We allow extending other types from TS, but you can safely assume that for now in Python it's not possible. We can save support for that in the future
We can do it in Python, but I thought we were no longer doing that.
No it's still being done in the yarn extension for example today. I just wouldn't put any extra effort into supporting it in Python, it's not a priority at all right now
If it comes for free (like it did in TS), then that's totally fine too
Hmm. I thought I read something about not doing it by design (in the future). Can't recall where. May be wrong then.
It's totally possible to do it in Python, I'm just not sure about the difficulties with others or what "comes for free" mean.
We've talked about and considered whether restricting that is a better choice in terms of DX (also may simplify problems for us), but it's still highly up for debate. There's lots of tradeoffs.
By "comes for free" I just mean don't put any extra effort in supporting the use case of extending types from other extensions. Our only primary goal is to support defining+extending types from within the extension for now. If the code you write for that happens to also give you support for extending types from other extensions, that's great too, don't try to like disable it or anything. That's what happened with TS for example, it just worked without any extra effort.
Yeah, the library has support for it. I think it's just a matter of unpacking the parent value. That's why I asked, to see how other sdks serialize theirs. But there's no equivalent to an object instance in either Go or the current nodejs implementation.
It's hidden in Go from users in the current cloak branch, but parent is supported in the new code-first schema: https://github.com/dagger/dagger/blob/043e9adb55093af933341e60286e3d7b0c353458/core/integration/testdata/codetoschema/main.go#L62-L72
And in TS you can optionally ask for the parent as an arg in your resolver
I may be misunderstanding though
Let's say you have this schema implemented in Go and JS (for comparison):
type Hello {
greeting: String!
}
type Query {
hello: Hello!
}
With the following query:
{
hello {
greeting
}
}
So first Query.hello is called, then Hello.greeting.
In Python, the result of Query.hello is a Hello() object. What is the return in Go and TS sdk? Empty {}?
Oh so you're just asking about the top level objects right under Query? Then yes, those specifically will always be {} in Go currently. In practice they also are in our current TS examples, though you could easily return an actual object if you wanted
Not just top level, any level.
Ah okay, yeah it's just a matter of returning an object from your resolver. Whatever you return will become the parent to any subresolvers. The only requirement for the object is that it is json serializable
It's what's written to /outputs/dagger.json, e.g. in the TS sdk that happens here: https://github.com/sipsma/dagger/blob/043e9adb55093af933341e60286e3d7b0c353458/sdk/nodejs/dagger/server.ts#L55-L55
Yes, I'm getting there, sorry if I'm not explaining correctly ๐ What I'm really interested is in understanding cases where a value is serialized in one sdk and then unserializing it in Python. The opposite as well. So I'm trying to think of a situation where that'll be difficult.
And testing my assumptions.
In JS, it's pretty basic. It's using plain objects instead of class instances.
That's why I'm wondering about Go for example. But if you use structs that can easily be marshaled into json (mostly).
Yeah that's the rule pretty much, you have to return something that is json serializable. Whatever you return will be marshaled into json and then unmarshaled into whatever else the SDKs want to unmarshal it into
Yeah I get that ๐ I think I'll need to come up with concrete examples to test these boundaries. I'm not there 100%.
Thanks for the assist ๐
For sure! Happy to help and glad to have someone else thinking about all this too, please break things and find problems (or else our users will eventually) ๐