plush moth
Replying to #go message
Hi Karl, we are working on a feature to customize how to run the engine container. In the meantime you could add a shell script called docker in your shell’s search path:
cat > /usr/local/bin/docker <<‘EOF’
#!/bin/sh
orb docker $*
EOF
chmod +x /usr/local/bin/docker
After that, dsgger should execute the script as if it were regular docker.
rose gate
out of curiosity, is there a reason (beyond ease) that we don't directly talk to the docker api using the go bindings?
that way, we wouldn't rely on the docker cli being available, we just need the socket to connect to
if there's not, i might pick that up sometime 😄
plush moth
out of curiosity, is there a reason (beyond ease) that we don't directly talk to...
there was a whole debate about that a while ago 😁
rose gate
👀
plush moth
rose gate
ohhh interesting ok, so i think this might actually be less of a concern 👀
i think the go client api can use the "docker contexts" feature, so you can configure that to point to wherever you want
this is how buildx does it
the main reason i'd really like to do it is because you get significantly better progress through the api, you can track exact progress of pulling an image, etc
atm "starting the engine" is a bit of a black box
plush moth
atm "starting the engine" is a bit of a black box
Yes agreed!!
plush moth
Yes agreed!!
On that point I think splitting “downloading the engine” from “starting the engine” would go a long way..
When things get slow I always wonder if it’s one or the other
rose gate
lol i have good news for you
this was in 0.9.4 https://github.com/dagger/dagger/pull/6075
plush moth
the main reason i'd really like to do it is because you get significantly better...
I’m curious how engine drivers affect all this
