I noticed this this using the docker cli | Dagger | Page 1

lime terrace Mar 18, 2023, 6:23 PM

#

I guess it is managing docker context's.

naive furnace Mar 18, 2023, 11:22 PM

#

this line?

CacheConfigEnvName = "_EXPERIMENTAL_DAGGER_CACHE_CONFIG"

runic pulsar Mar 19, 2023, 4:23 AM

#

@naive furnace I think he refers to the file in general since we exec docker run here https://github.com/dagger/dagger/blob/0100316a0b53c307a1311c29006529ec4f026660/internal/engine/docker.go#L89-L99 instead of using the Go client directly.

IIRC we're bootstraping the engine this way since it introduces less coupling to the bootstrap process strategy, correct?

naive furnace Mar 19, 2023, 6:23 PM

#

This has been discussed a long time ago, I don’t remember why we kept the docker dependency but it’s probably explained here: https://github.com/dagger/dagger/issues/538

GitHub

Remove dependency on `docker` client binary · Issue #538 · dagger/d...

In some situations, Dagger needs to talk to a Docker daemon to setup its buildkit environment. Currently it does this by shelling out to the docker command. If the docker command is not installed, ...

runic pulsar Mar 19, 2023, 9:23 PM

#

+1 another advantage is that with the current approach que have podman support out of the box since for what I've seen in the wild everyone just aliases podman to docker as it's suggested in the podman docs

buoyant oak Mar 20, 2023, 8:27 PM

#

^ Also I know someone was able to use nerdctl instead of the actual docker cli for the same reason.

I'd say that in general I probably wouldn't be opposed to leaving in the current code but having a fallback that uses the docker API client directly in case the CLI isn't available. It would be an unfortunate complication to the code but if the CLI requirement is causing big headaches then this is definitely worth considering I think.

terse ginkgo Mar 31, 2023, 3:55 PM

#

I was searching through the feedback to see if anybody was talking about this and wanted to leave my 2 cents: I'm currently trying to get our first dagger-based tool into our existing pipeline, which runs on a bunch of different docker images -- some of them already have the docker CLI and some don't. And installing the CLI properly is a Whole Thing involving adding an apt repo and the keys for the apt repo and/or manually installing buildx.

On my own dev machine like, yeah, docker is always going to be there -- and if I were making a new image just to bootstrap a dagger process it'd make total sense to include it. But it's a surprising bit of friction at the point of first adopting the tool.

#

@buoyant oak @naive furnace ^

runic pulsar Mar 31, 2023, 4:00 PM

#

terse ginkgo I was searching through the feedback to see if anybody was talking about this an...

@terse ginkgo those that don't have the docker CLI what do they use currently to build containers?

terse ginkgo Mar 31, 2023, 4:00 PM

#

they don't!

#

🙃

#

I guess more context is probably appropriate here -- and now I'm thinking about it, maybe I'm the weird case out...

runic pulsar Mar 31, 2023, 4:01 PM

#

so you're saying that installing docker for them is complex?

terse ginkgo Mar 31, 2023, 4:01 PM

#

not insurmountably, but annoying

runic pulsar Mar 31, 2023, 4:03 PM

#

your argument is totally valid and we discussed this in the past to eventually remove the docker dependency. IIRC there's even an issue for that. That's coming, it's just that it hasn't hit the priority bell yet

terse ginkgo Mar 31, 2023, 4:04 PM

#

well, the context (which may make me less compelling): my first use for dagger is to create a storage layer that will transfer (non-container) build artifacts between various jobs. I'm doing this by creating empty containers that include only build files

#I noticed this this using the docker cli