Is there a way to call dagger functions programatically?

[nimble flame]

Let's say that i first developed my dagger function with it's dependencies and so on.

Later on I want to create a website that reuses that logic in the backend, is there a way to do something like:

import dagger
dagger.call(...)

I would like to avoid using exec alike functions 😅

[rain basalt]

I have also ran into this problem.

[nimble flame]

it's kind of similar, not sure if i like the workaround, gotta try it out

just saw this message @dreamy quartz #1226443956213121105 message it only seems accesible through go sdk

[rain basalt]

Yeah, working with lower level GraphQL via the client sort of side-steps having functions/ using the dag object and being able to use their abstractions, which one would imagine should also be executable via consuming code. I still am not sure why this can't work. My main problem is, I'm new to Go too. So, I am uncertain of how to mix contexts between applications and if that is even possible or if that is even what is needed. LOL!

[merry root]

We want to support this in a first class way, the issue to track the progress of that can be found here: https://github.com/dagger/dagger/issues/5993

[nimble flame]

I am not sure reading this is that if I would be able to do so using a different sdk other than go

What I would like to do is:

• Create a dagger module Foo made in Go that depends on a different Go module Bar
• Create a website backend in typescript that can reuse this go modules so i have both the website and the CLI

The workaround atm is not possible because it seems like the graphql class is not available neither in python and ts

If it was possible doing grapqhl requests manually would not be that bad

I mean otherwise I just simply can do it the "old fashion" way with different microservices communicating with rpc for instance, just wondering if this was possible or planned at all

[lone kindle]

you can query the graphql directly

you just won't have generated client bindings

just exec dagger query -m MODULE and write the graphql query to its standard input

you will get the json-formatted output

Example:

dagger query -m github.com/shykes/daggerverse/hello  <<EOF
{
 hello {
  hello(greeting: "bonjour", name: "monde")
 }
}
EOF

Output should be:

{
    "hello": {
        "hello": "bonjour, monde!"
    }
}

You'll have to deal with IDs yourself, too

[dreamy quartz]

it is available, beauty of dynamic languages 🙂

connect(
  async (client: Client) => {
    await client
      .moduleSource("github.com/shykes/daggerverse/hello")
      .asModule()
      .initialize()
      .serve();
    const res = await (
      await client["_ctx"].connection()
    ).request(gql`
      query {
        hello {
          hello
        }
      }
    `);
    console.log(res);
  },
  { LogOutput: process.stderr },
);

also works with python

cc @austere tapir not sure if there's a less hacky way to get access to the underlying graphql client 🤔

[nimble flame]

gotta try this out definetely ty 🫶🏻

[austere tapir]

No because I do not expose it but I can open a PR to add this change to our API, it's not a big deal.

Like await dag.getGQLClient() that returns you a connected client, this could work but I also need to take care of the closing

[nimble flame]

That would be awesome!!

[tender lava]

Yeah I thought about the same thing for Python since the Lisbon hackathon because it would’ve helped me then but I had to rush.

[nimble flame]

@austere tapir is there any issue about that so i can keep track of that feature? 👀

[austere tapir]

No sorry, but I'm going to implement this tomorrow if that's okay?

I'm going to create it right now

Here: https://github.com/dagger/dagger/issues/7159

[nimble flame]

it wasnt a hurry tho, just to know when to retake the project i was planning to use it:P

ty very much ❤️

[dusky wing]

Coming back around to this thread. I see a GitHub issue to implement this in TypeScript but nothing for Python and Go. Is that because this is already supported the Go and Python SDKs or because we want to add the feature to TS? I want to make sure we're not causing feature drift between the SDKs. Also, is that the right way to implement it? Should we have a more generic method that is available to all the SDKs, such as the one Lev linked earlier?

cc @velvet wind @tender lava @trail lotus

[tender lava]

There is actually: https://github.com/dagger/dagger/issues/7182

Go has it already.

[austere tapir]

A bit late but here's the PR to should allow directly calling the GQL client from the TS SDK
https://github.com/dagger/dagger/pull/7294

I'm waiting for a review before merging it

/cc @tender lava @dreamy quartz

[nimble flame]

ty ver much, really apreciate it ❤️

[paper condor]

Does this make it possible to call functions from the older dagger run ... style code?

[dreamy quartz]

it's not the UX that we'd like but yes, you can do it today by sending a request to the GraphQL server

[paper condor]

agree, not the desired UX, but something that could be done was what I was after, kick the tires and what not

[rain basalt]

I believe, (and I'd love to be corrected, because I'm still not 100% clear if what I'm about to say is true), that this design discussion is about allowing programmatic control of Dagger from another program. Again, please anyone do correct me, if I am wrong. 🙂

[paper condor]

I think it is more about what directory context is the default for a module. Imagine writing a function that builds a Go application, packages it as a container, and ships it off to a registry. Ideally you should be able to run that in any directory and it should just work, without having to pass the directory as a argument

That's my understanding from skimming a bit of it the other day anyhow

[rain basalt]

Yeah, when they switched to the directory bit, I got even more confused. I thought the "context" being mentioned at the start of the discussion was about Go application context sharing. But, I'm very new to Go too, so I wasn't certain. And, I'm still confused. 😛

As I see how things work currently, I must run exec commands in my application, in order to run the Dagger CLI to run Dagger Modules/ functions and capture the results, parse them to determine success or failure and move on from there. Again, just learning, so if that sounds silly, please do correct me. 🙂

[tender lava]

No, the contextual modules proposal is not at all about that. It's also not specific to Go, it's related to how modules are loaded by the CLI. It's aimed at simplifying where dagger files go when you create a module, and gives more access from function code to the parent directory. Today you need to pass that directory as an argument to the function.

So, it's unrelated to the topic in this thread as nothing changes from that POV with this proposal.