#By any chance, is anyone still around
golden drum
@plucky lotus thanks 🙂 I'm playing with improvements to dagger functions
I found the FuncCommand.mod field, and the really cool types behind that, with seemingly everything I need
But when I load the main object, and call GetFunctions, it doesn't find any
Let me share a github link, it will be simpler. It's pretty simple code
@plucky lotus this is what I'm doing: https://github.com/dagger/dagger/pull/6315/commits/a1571eb3f7b2e8acb1933d591abdcdf9ef1e82e6
This is where I "walk the pipeline" myself: https://github.com/dagger/dagger/blob/a1571eb3f7b2e8acb1933d591abdcdf9ef1e82e6/cmd/dagger/functions.go#L46-L50
plucky lotus
I think it might be this line: https://github.com/dagger/dagger/pull/6315/commits/a1571eb3f7b2e8acb1933d591abdcdf9ef1e82e6#diff-5776ff0964ca98cf11dfeea0d49469d367ae59dad47427190f6dbdf53004c20aR694
In our TypeDef api (which those types like modObject are light wrappers around), we distinguish between Field and Function. Fields being the static fields of the objects you define (which are special because they can be resolved without a full rpc) and functions being the actual methods you define on the objects (which need a full rpc to resolve).
From a client perspective, they all become graphql fields, but the difference between the two is still being made at the level of that code.
So basically I think you just need to also iterate over modObject.Functions in addition to modObject.Fields
golden drum
But I copy-pasted GetFunctions
plucky lotus
But I copy-pasted `GetFunctions`
That one appends o.Functions... too: https://github.com/sipsma/dagger/blob/04ca77b734889252efd118a87ca4ed017923f486/cmd/dagger/module.go#L688-L688
I guess it's a little confusing in the naming because both o.Fields and o.Functions all get turned into a modFunction type (that's where the distinguishing between them ends in the current cli codebase), but that's what's happening there
golden drum
oh you're right! I missed that last append
Makes sense
I actually love that they're mixed together at this point
Since really we want fields and functions to be one and the same
(I know reality is more complicated)
plucky lotus
Yep exactly, fields are just functions w/ no args as far as the clients know (other optimizations are internal only)
golden drum
I think you found my problem! I'll try it right away
I should have just called GetFunctions and iterated on the result but nooo I had to optimize
plucky lotus
Yeah I know, hopefully computers someday will do what you want rather than what you tell them...
We can dream
golden drum
OK it half-fixed it 🙂
I feel like I'm not understanding how to use this API
This is correct:
$ ./bin/dagger functions -s -m github.com/shykes/daggerverse/wolfi
base Initialize a Wolfi base configuration
$
$./bin/dagger functions -s -m github.com/shykes/daggerverse/wolfi base
$
This is not correct - prints nothing. It should find functions 🤔
$ ./bin/dagger functions -s -m github.com/shykes/daggerverse/wolfi base container
Error: no function 'container' in object type 'WolfiConfig'
This is not correct - it should print the contents of a Container type (if that's supported?)
plucky lotus
You should be able to see the container function on WolfiConfig... if you push the updated code I can look again
golden drum
For reference, with 0.9.4:
$ $ dagger functions -s -m github.com/shykes/daggerverse/wolfi
object name function name description return type
*Wolfi base Initialize a Wolfi base configuration WolfiConfig!
WolfiConfig packages [String!]!
WolfiConfig overlays [Container!]!
WolfiConfig withPackage At a package to this configuration WolfiConfig!
WolfiConfig withPackages Add a list of packages to this configuration WolfiConfig!
WolfiConfig withOverlay Add an overlay to the current configuration.
See https://twitter.com/ibuildthecloud/status/1721306361999597884 WolfiConfig!
WolfiConfig container The container for this configuration Container!
Oh actually, what happens right now if you do
dagger function -s -m github.com/shykes/daggerverse/wolfi Base Container
golden drum
oooh
$ ./bin/dagger functions -s -m github.com/shykes/daggerverse/wolfi Base
Error: no function 'Base' in object type 'Wolfi'
$ ./bin/dagger functions -s -m github.com/shykes/daggerverse/wolfi Base Container
Error: no function 'Base' in object type 'Wolfi'
Here's the PR: https://github.com/dagger/dagger/pull/6315
plucky lotus
Ah okay yeah it's a subtly in how TypeDefs work again, this fixes that problem:
diff --git a/cmd/dagger/functions.go b/cmd/dagger/functions.go
index 935a0bca8..1ef2271a5 100644
--- a/cmd/dagger/functions.go
+++ b/cmd/dagger/functions.go
@@ -53,7 +53,7 @@ var funcListCmd = &FuncCommand{
}
nextType := nextFunc.ReturnType
if nextType.AsObject != nil {
- o = nextType.AsObject
+ o = fc.mod.GetObject(nextType.AsObject.Name)
continue
}
// FIXME: handle arrays of objects
Basically, when we're returning the hierarchies of TypeDefs from the API and an object shows up as an output/input type to a function, we just return a TypeDef with a name of the object rather than the full object definition. You can get the full object definition only from the "top-level" returned object on the api call.
The reason is that if we repeated the full object definition every time you'd at best be using O(n^2) space in the result and at worst cause json serialization errors due to cyclic references (i.e. with* functions on an object that return the object itself).
So that diff just results in using the "full definition" of the object rather than the one that's just a reference to it by name
(None of which is at all obvious of course)
golden drum
It worked!