#Dagger CLI with Deno

1 messages · Page 1 of 1 (latest)

rich canyon
#

If that’s how it works, that’s really smart and I love it. I got it in my head that it would be cool to use Dagger’s node SDK from Deno (because typescript is built in and I want to explore implementing some kind of platform orchestrator using Deno with Dagger as a backend) and I was afraid dagger run node was built-in.

#

I haven’t gotten the node SDK to work under Deno yet—there are probably some incompatibilities with deno’s NPM compat layer.

copper oxide
#

@neon sparrow would be the expert here 🙂

rich canyon
#

Wow, wait a minute. I think I can get Dagger to run under Deno when using dagger cli, but not when just invoking deno directly! Curious

neon sparrow
#

It just sets a couple of env vars that the SDK uses to connect, but you can also just run curl or something; there's an example of that in dagger run --help:

  Run a Dagger API request directly:
    jq -n '{query:"{container{id}}"}' | \
      dagger run sh -c 'curl -s \
        -u $DAGGER_SESSION_TOKEN: \
        -H "content-type:application/json" \
        -d @- \
        http://127.0.0.1:$DAGGER_SESSION_PORT/query'
rich canyon
#

I was just looking at that actually -- nice. Hmm -- you know, I'll bet that's related to my issue with Deno.

#

So dagger run has the CLI create the session with the dagger engine; possibly creating it on the fly using the local docker, and then passes those env vars to the child process so it can just communicate with the engine

#

Whereas if I try to invoke the Deno script directly, I get this ```error: Uncaught InitEngineSessionBinaryError: failed to download dagger cli binary: TypeError: d.pipe is not a function
at G.<anonymous> (https://esm.sh/v124/@dagger.io/dagger@0.6.0/deno/dagger.mjs:8:23837)
at Generator.throw (<anonymous>)
at T (https://esm.sh/v124/@dagger.io/dagger@0.6.0/deno/dagger.mjs:8:22256)
at eventLoopTick (ext:core/01_core.js:181:11)
Caused by: TypeError: d.pipe is not a function
at https://esm.sh/v124/@dagger.io/dagger@0.6.0/deno/dagger.mjs:9:679
at new Promise (<anonymous>)
at G.<anonymous> (https://esm.sh/v124/@dagger.io/dagger@0.6.0/deno/dagger.mjs:9:618)
at Generator.next (<anonymous>)
at l (https://esm.sh/v124/@dagger.io/dagger@0.6.0/deno/dagger.mjs:8:22205)
at eventLoopTick (ext:core/01_core.js:181:11)

#

So I guess that tells me that the SDK will actually use the CLI under the hood to communicate with the dagger engine? And something in Deno's node compat layer is breaking when it tries to do so

#

But when running under dagger run deno run -A ci/index.ts, it doesn't have to

neon sparrow
#

Yep - the SDKs all shell out to dagger session if invoked directly, but when you use dagger run it runs the session in dagger run instead to avoid an extra exec

#

(Sidebar: we'll need to make it a bit more airtight; right now it's possible to have your local userland dagger CLI out of sync with the version the SDK wants, which could explain some breakage, not sure about this one though.)

rich canyon
#

Cool, glad I understand how that works. I'm sure this breakage is deno-related, but it's neat that it seems to work OK inside dagger run. Have you heard of anyone else trying to use dagger with deno?

#

(just did a discord search and found some prior posts, actually)