Thank you! That got my brain turning and

[woven anchor]

Is the dagger module co-located in the same repo as the application? If so, you should be able to get it to to work on the current version

[shrewd bolt]

yep, same repo

adding a go workspace caused some dreaded ambiguous import issues that i couldn't resolve after a few hours of peeling things apart. from some grpc/otel packages in internal/telemetry

[woven anchor]

I see, you're trying to add the dagger module to the same workspace as the app?

[shrewd bolt]

I had tried to use go workspace in an attempt to keep my dagger module and app go module separate. I just now gave a fresh try to dropping the go.mod out of my dagger module and treating it all as one go module and got the same 'terminal prompts' disabled error.

Thats when I realized I had most of the repo exlcuded in dagger.json, in an attempt to keep the resolve module stuff smaller.

Cleared that out, and now dagger develop works

But... much slower, since the rest of the repo is 468MB 😓

anyway, i'm unblocked it looks like. you're awesome!

[woven anchor]

Unclear how I helped here, but glad you're unblocked 🙂

[woven anchor]

Are you able to share a Trace link via dagger cloud? That way we could double check the source of the slowness together. You shouldn't have to deal with slow loading

[shrewd bolt]

Sure, when I have a new example worth spending your time on, i don't want to waste it. I hadn't seen any slow (1-3 minute) 'modulesource' tasks since i did my exclude list in dagger.json; last week. Right now it's just a few seconds.

[woven anchor]

Just to confirm your current situation: you were able to add the dagger module to the same go workspace as your app, and everything works properly? dagger develop works, you get auto-complete in your IDE etc?

And aren't you still stuck in this "hard" blocker ?

my dagger module needs to work with types from my application go module

[shrewd bolt]

I'm not using go workspaces, I have a golang mono repo with a root go.mod . I previously had ./mydaggermodule/go.mod and now ./mydaggermodule is a part of the root go module.

[woven anchor]

Have you tried the following setup:

• dagger.json at the root, with "source": ".dagger"
• Dagger module has its own go module at.dagger/go.mod
• Code from the dagger module imports code from the root module as needed, eg import "yourmodule.tld/foo/bar"

[shrewd bolt]

Yeah, that was the original setup, but it required a go workspace to work with without pushing changes. As soon as I go work init, I ran into unresolvable ambiguous import errors just like this dev: #go message. He resolved his issues by deleting his go workspace.

[woven anchor]

Sorry if I'm missing something obvious. What do you mean by:

it required a go workspace to work with without pushing changes

[shrewd bolt]

Without a go.work, the dagger module importing code from the root module yourmodule.tld/foo/bar (bar package not pushed yet) , a dagger develop results in a go get from yourmodule.tld/foo/bar which doesn't exist yet. and is a private repo and causes a password prompt. I add a go.work and it contains uses ./, the go get succeeds. But, the ambiguous import error prevents actually working with this setup.

[woven anchor]

ah I see. Is there a possibility of using a replace directive instead in the dagger module's go.mod?

Perhaps we could do this automatically ("we" meaning the dagger go sdk)

[shrewd bolt]

That may work, I'll try it out after i'm finished proving out my use case. I'm running into a new issue now though 😅 In a package outside of my dagger module, I have a function accepting *dagger.Client but i can't pass dag into it from the dagger module, since it's a gen'd internal type not from "dagger.io/dagger"

[woven anchor]

ah I see... Yeah if we're talking about dagger-specific code, it's best to not rely on Go imports for reusing logic, exactly for this kind of reasons

We haven't stuck the landing for the case where you already had a large body of code predating Dagger Functions - like seems to be the case for you

In my experience porting pipelines over to the Functions model - it's usually easier to copy-paste the code and convert it all to Dagger Functions as you go

so far it's always been relatively easy to do, and usually made the code simpler too

[shrewd bolt]

To be clear, I'm starting fresh with dagger functions, I don't have a dagger SDK based codebase I'm porting. The code i'm writing now is a mechanism to dynamically add things to the dagger graph. I'll try defining an interface that matches the signature of the internal dagger.Client and see how it goes.

[woven anchor]

Going off of this information, I would recommend writing all that code directly as Dagger Functions, effectively removing the need to pass a Dagger client at all

My guess is that it would be easier to fit what you're trying to do in the Functions paradigm, than solve the issues caused by stitching Functions and non-Functions logic together (eg. passing a generated dagger.Client to a function that expects a non-codegened one etc)

[shrewd bolt]

Totally agree, I'll see what I can come up with

Ideally I'd like to distill a complete example of the pattern i'm trying to implement, distinct from my company's IP

[stone estuary]

that'd help a lot to provide more accurate feedback. We have some user users in the community dealing with monorepos so it'd be great to contrast the different approaches 💪

[shrewd bolt]

So if I put my custom type in the dagger module, it can access the various types within it, but the dagger module isn't importable, so my custom type isn't accessible by my application code. If i put my custom type in my application code, it can't access the various types within the dagger module, but it is accessible by my application code.

[woven anchor]

it seems that these custom types are related to Dagger. In that case I would move them all to the module, then narrow the dependency from your app to a very simple call to a Dagger Function that serves as entrypoint. Then call that from your external code. You can do this by either A) making a raw graphql query with the official dagger client library, or B) copying the generated bindings for your module from internal/dagger into your app's module.

just to be clear it seems like your app has some sort of dagger-aware logic within it? so it's fair to say it's not a "regular" app?

[shrewd bolt]

yeah, its not a regular app. as far as implementation goes, what i'm doing is similar to what the folks have done in grafana-build

[stone estuary]

@shrewd bolt you can however import the Dagger's module types into your code by using replace directives in your main app's go.mod correct? Just tested this and it works:

.
├── dagger
│   ├── dagger.gen.go
│   ├── go.mod
│   ├── go.sum
│   ├── internal
│   │   ├── dagger
│   │   │   └── dagger.gen.go
│   ├── main.go
│   └── types
│       └── types.go
├── dagger.json
├── go.mod
├── LICENSE
└── main.go

7 directories, 21 files

go.mod of the main app:

module lala

go 1.22.4

replace dagger v0.0.0 => ./dagger

require dagger v0.0.0

app main.go:

package main

import (
    "dagger/types"
    "fmt"
)

func main() {

    fmt.Println("hello")

    t := types.FooType{}

    fmt.Println(t)

}

[shrewd bolt]

that indeed does allow my app module to use types in the dagger module, but it doesn't allow the dagger module to use types in the app module, right?

[stone estuary]

yes, you can also do the same the other way around. Add a replace in your dagger module that references your root go module

that also works

[shrewd bolt]

interesting

[shrewd bolt]

Thank you so much Marcos! I'm stoked I don't need to revert to pre-dagger function/module approaches. I was able to get what I needed working, both with and without the replace directive. I think I was being silly and got my head twisted regarding access to go internal packages.

[stone estuary]

Sure! Happy to help! How did you get into work without the replace directive?

[shrewd bolt]

I dropped the ./dagger/go.mod out and made it part of the root go module. It behaves the same way as a separate go module. Imports are the same, the only different being the replace directive. Is it advised to keep the dagger module a separate go module?

[woven anchor]

We're debating what layout is best by default and currently leaning towards separate go module (although not yet settled, in part because of user feedback such as yours). But regardless of what default we pick, you're free to choose a layout that works for you.