#go workspaces: dagger func -> normal go func in another module

1 messages · Page 1 of 1 (latest)

worn aspen
#

go workspace setup question: dagger function -> normal go module: how to set up the go workspace so the codegen for the dagger function finds the module it depends on?

I have a dagger function that calls into some private module's code and it works just fine. Until I tried to optimize my local dev situation and put them both inside of a go workspace.

I searched the discord and found 2 messages, one seemed to not be the same issue as this was someone in 2024 trying to call a Dagger Function from normal go code, whereas, in my case, this the reverse chain.

#

sorry, I lost half the message here after trying to move it to #go , hitting a length limit and then trying to move it back.

LMK if more info is needed. 🙂

devout canopy
worn aspen
#

no, just putting them in the same workspace seemed to just not include the changes I was making in the dependency. (changed a quick fmt.Print to verify that - message continued to print in the same way, w/out the updated string..)

I tried then using an explicit replace in the go.mod of the dagger module, but then the codegen step told me it couldn't find ../../other_module essentially.

I tried some stuff like running dagger develop in the workspace root dir and then calling the module from there by using the dagger call --mod dagger/my-dagger-module ... but the couldn't find ../../other_module message persisted.

My guess is that the client is only uploading the actual dagger module directory to the engine, and not the entire go workspace - but, I could just be Doing It Wrong™ 🙂

#

the dependency is a private git repo that I need to clone via SSH if that matters. (seems to work fine w/out the go workspace, but adding the workspace to reduce my work from tagging and pushing a pre-release for every change in the dep, and then re-running go get in the dagger module, to just editing it locally, isn't working with my current approach and setup for reasons I am unable to discern currently unfortunately)

#

I'm not blocked, so not a huge deal, I'd just like to have a slightly smoother localdev setup (if possible - current one w/ tag, push, pre-release, go get is functional)

#

the dagger docs (https://docs.dagger.io/extending/modules/#go-workspaces) seem to talk about having all the dagger modules inside a monorepo, which is a slightly different issue.

Anyway, just looking for a sanity check, really. If this is a normal thing that is expected to work and I'm just doing something wrong (very likely IMO), or if this setup is outside of what is currently directly supported w/out doing the little bit of extra work I'm already doing.
Thx for the help!

Module Initialization | Dagger

Learn how to initialize a Dagger module

devout canopy
#

@worn aspen gotcha. What you're trying to do can be achieved. Let me share with you a quick example

#

so you configure youer dagger.json to upload the workspace to the SDK runtime codegen part

worn aspen
#

sweet! I'll check that out this afternoon! thanks!

#

I see you just pushed that up 1 hour ago - so I just wanted to say I really appreciate you taking time out of your day to make a working PoC for this question - above and beyond what I expected and was asking for - I am very grateful. thx! daggerfire