#Dagger CLI with Deno
1 messages · Page 1 of 1 (latest)
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.
@neon sparrow would be the expert here 🙂
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
Yep that's how it works. 🙂 For example dagger run ls
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'
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
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.)