Exposing a dagger.Directory to SDK-native code

[jovial girder]

So let's say I want to do a git diff.. I can pass a *dagger.Directory into my function and then mount it into an e.g. alpine/git container and run a git diff. All good.
But what if I wanted to re-implement this using platform-native code, like go-git. On the host, I could do git.PlainOpen(".") to work with the git repository. So if I have plain old, top-level Go code in my function (and not a tool in a container), how do I expose the *dagger.Directory to it ? Is that even possible?

[pearl snow]

👋 you can call directory.Export("/foo/bar") and then call git.PlainOpen("/foo/bar") from your module's code.

[jovial girder]

So if I'm already e.g. in a GHA context with the repo checked out locally, I can just skip that and git.PlainOpen(".") anyway? Wasn't sure if functions automatically have access to the host context or not

[jovial girder]

Hm no that doesn't work so I must be missing something. What do you mean by "from your module's code" exactly? The context in which I'm trying to git.PlainOpen() is a Dagger function.

[pearl snow]

you can't do that directly in your function because functions are sandboxed and only have access to what you pass them explicitly. That's why you send a *dagger.Directory as an argument and then you can call Export on that directory so the files are exported to the sandbox environment

[pearl snow]

module's code = function. I was referring to the same thing

This makes it a much more secure model because your function's code can't just access anything in the host.

[jovial girder]

I get the security argument for sure. But once I already pass in the *dagger.Directory, I want to be able to use native code to work with those files, which currently I can only do in a limited fashion (whatever the *dagger.Directory API exposes to me). So if I actually want to provide some functionality of go-git as a function, I'll have to copy all the files from the *dagger.Directory to an in-memory filesystem (that go-git luckily supports). But I don't see how I can ever use something like git.PlainOpen(".") in this context.
There would have to be some kind of dag.GoContainer().WithMountedDirectory().WithGoFunc(myGoGitFunction) that would have to be able to somehow compile and run that function inside a go SDK container or something complicated like that.

[pearl snow]

I want to be able to use native code to work with those files, which currently I can only do in a limited fashion (whatever the *dagger.Directory API exposes to me).

is the directory.Export approach I suggested above not working for you?

[jovial girder]

Nope, maybe some pseudo code would be helpful. I'm pretty sure I'm misunderstanding what you mean by that.

In my current understanding, it shouldn't work, since once I export the directory, it's on the host filesystem, which I cannot access directly from a function because of the sandbox. So same issue.

[pearl snow]

calling Export inside a function exports the code to the sandbox, not the host filesystem

here's an example:

func (m *Lala) Test(dir *dagger.Directory) *dagger.Container {
    dir.Export(context.Background(), "/foo/bar")

    g, _ := git.PlainOpen("/foo/bar")

    return dag.Container().From("alpine")

}

Host access can only happen via function inputs/outputs

[jovial girder]

Oh, I see, my bad.. Yes I have tried something like that, didn't work, but I may have wrote it off too soon based on the misunderstanding, so I'll see if I can try "harder" 😅 thanks

[pearl snow]

np! LMK if you're still having issues and we can check it out together!

[jovial girder]

Yep, this works perfectly fine, I think I've passed the wrong --source / was not in the git root when I tried it before 🤦

[pearl snow]

awesome!