Supports running Dangerzone on Mac with Docker Desktop compatible clients

[d7an]

First, I'd like to acknowledge that it's documented on your site that macOS requires Docker Desktop.

However, docker compatible/replacement clients like Rancher and OrbStack has pretty good compatibility mode, and I'd like to see if I can avoid installing Docker Desktop on my machine again as I'm really happy with one of these replacement.

FYI, I'm able to load the dangerzone image using the cli
docker load -i /Applications/Dangerzone.app/Contents/MacOS/share/container.tar.gz

The question is, what is it checking upon startup that makes it think it requires Docker Desktop? Would it not work with these Docker replacement clients?

I've Dangerzone 0.4.2, OrbStack 1.0.0_16230

[deeplow]

We haven't explored these alternatives, but thanks for mentioning them. We also want to go away from Docker Desktop (see issue #118).

The question is, what is it checking upon startup that makes it think it requires Docker Desktop? Would it not work with these Docker replacement clients?

We're checking if there is a program called "docker" explicitly (if you understand python, check this line). That's why these aren't being detected. While we won't be able to add official support to them we can consider broadening this search some other compatible platforms. What do you think @apyrgio?

[d7an]

We haven't explored these alternatives, but thanks for mentioning them. We also want to go away from Docker Desktop (see issue #118).

The question is, what is it checking upon startup that makes it think it requires Docker Desktop? Would it not work with these Docker replacement clients?

We're checking if there is a program called "docker" explicitly (if you understand python, check this line). That's why these aren't being detected. While we won't be able to add official support to them we can consider broadening this search some other compatible platforms. What do you think @apyrgio?

BINGO! Thanks for the pointer, it works flawlessly with OrbStack (with a small tweak), and probably will also work with Rancher Desktop.

The "problem" is exactly what it said, it can't find "docker".
Rancher Desktop keeps a copy under ~/.rd/bin/docker
OrbStack keeps a copy under /Applications/OrbStack.app/Contents/MacOS/xbin/docker

I made a symlink to /usr/local/bin and Dangerzone works "OOTB" from there.

What might be useful before #118 is implemented is a user Settings if it can't find Docker, to allow user to point to where their copy of "docker" is. Thanks!

[deeplow]

Glad you got it working. Probably this is a very niche situation and the symlink idea seems like a good fix for the time being. If anything were to be implemented, I'd rather make it automagically rathen than a toggle in the settings.

It's the thing that seems like it could be useful in the settings until one realizes that if we did for every open we find this it would end being pretty hard for novice users to navigate the settings. Basically it become like piped piper (Silicon Valley reference):

Others coming across the issue will hopefully find their way to this thread. I'll let @apyrgio weight in if he has any comments before closing this.

[apyrgio]

Yeap, first thing I would suggest is the symlink way. Next up would be to have a list of known executables to check if docker is missing. This would allow for Podman Desktop and others to be used. After all, there are not many Docker Desktop alternatives out there. Third would be to update this error message with a link to our wiki page, which would suggest to symlink your container runtime of your choice as docker.

Also, I agree with @deeplow, having "advanced user" options is something we'd like to avoid until we have a clear way to present it to users. This may seem theoretical at first, but take a look at #374 (comment). In that case, the user has Docker installed, but it's not in PATH, so they rightfully want to specify the path where Dangerzone should look for this executable. So, adding support for these two niche cases would confuse the user, and we want to approach this with care.

Closing this issue as there is a workaround for it. We can keep the discussion open though if there are any more concerns.