I _may_ have hit a blocker with modules

[hard escarp]

Ah yeah, so we didn't forget about you and similar users who would hit problems here: https://github.com/dagger/dagger/issues/5913

But we haven't had time to fully flesh out support for removing all internet deps at runtime.

However, I am just now wondering if there could be a cheap fix for go at least, which is to use go mod vendor. Let me go test if that works

[hard escarp]

From my tests, it almost works, but there's a few modules that seem to not get vendored for some reason. Trying a little bit more...

[weary drift]

In my case, I don't have a problem going out to the internet to grab dependencies as long as the proxy is setup. I need a way to passthrough system proxy to the module runtime so that I can grab it with the module go code. Which is what I'm doing today with the non-zenith app.

I do have certain requirements to proxy via our internal artifactory instance in certain instances too.

For stuff like pulling docker images i have the SDK capabilities to pass the auth.

[hard escarp]

Yeah that makes sense and that's what we should enable to be configured for the best long-term solution. I was hoping that vendor/ might be a cheap+quick workaround in the meantime. I haven't quite given up hope on that yet, but may need to and think of the next shortest path to getting you unblocked. We may just need to add all the plumbing to make SDKs configurable (i.e. GOPROXY settings), which is what we want long-term anyways, it may just take a bit longer to implement.

[weary drift]

That's fair! Happy that support is in the backlog I will try out vendor and see how it goes, but in practice we don't really vendor modules generally in go projects so that won't be a viable long term solution for us. I am not entirely blocked right now as I can do development locally. Just can't run/test anything on or ci systems so looking forward to how this develops.

[weary drift]

@hard escarp I only have to vendor the module right? Doesn't seem to have worked, it's still doing a go mod tidy which is trying to pull from outside.

I didn't try doing dagger call from within the module folder. I wonder if that's causing it. I have to step away now but i'll try running from within the module folder.

what i did was dagger call -m ./go publish

[hard escarp]

Yeah that's what I've hit, and even after making a bunch of progress by jumping through hoops to pre-cache all the Go SDK deps in the engine image and use those, go is still insisting on trying to hit the outside in order to update go.sum at a certain point.

I've pretty much accepted this fate, I think we'll just need to do the plumbing to setup sdk configuration (which will include GOPROXY for the go sdk). I'll think through the shortest path to get something working there; just don't want a 100% pure hack that we regret later. Will think about it over the weekend