#@Erik Sipsma, `currentTypeDefs` doesn't
1 messages · Page 1 of 1 (latest)
It is supposed to include all the deps that the current client has loaded into their schema. Do you have an example where you're not seeing them?
In the case of the CLI, the deps would be core + whatever module you have called Serve on
Yeah, just running the query in GraphQL Studio, with dagger listen:
fragment TypeDefRefParts on TypeDef {
kind
asObject {
name
}
asList {
elementTypeDef {
kind
asObject {
name
}
}
}
}
fragment FunctionParts on Function {
name
returnType {
...TypeDefRefParts
}
}
query TypeDefs {
typeDefs: currentTypeDefs {
kind
asObject {
name
sourceModuleName
constructor {
...FunctionParts
}
functions {
...FunctionParts
}
}
}
}
The only non-empy sourceModuleName is the module.
Are you running that from the host directly? Or inside a module implementation?
From a host client (e.g. the CLI), their "deps" are just core and any module they have called Serve on. You wouldn't be expected to see the deps of the module you called Serve on since we hide transitive deps from the schema.
If you loaded a module and from it's implementation called currentTypeDefs then you would see the type defs of the dependencies that module has
I see. Yeah, I'm running in the host (CLI). I was looking to avoid having to load a dependency to run functions from it in dagger shell (cc @worn cedar).
For example, in our root module you'd just
⋈ wolfi container
To run the container function in the wolfi dependency. But right now I'll have to load that.
If the types were included in currentTypeDefs I'd have that introspection but I'd still need to serve that dependency so it makes sense.
Yeah exactly, I guess the analogy is that if you import a package A in go/typescript/python/etc. you don't just have the ability to call functions from package A's dependencies too (for most languages anyways, I guess C is an exception 😄 ). You have to explicitly import those deps too to call them. For us, just replace import with serve and it's the same idea
I have another question. Is there currently any workaround I can use to force reloading a module in a session? Otherwise you need to keep exiting dagger shell and re-enter to get some changes.
Obviously we'll have a real fix for that possible soon, but trying to think of any dumb hacks if you are just trying to iterate faster locally. All I can think of is tweaking include/exclude config in dagger.json (or you could just hardcode an append of a random string in the engine)