On a machine with both podman and docker installed, BoxBuddy silently shows only half the picture, and never says which half.
Distrobox picks its container manager by autodetection - podman first, then podman-launcher, then docker, then lilipod (distrobox-list, lines 174-186) - and only DBX_CONTAINER_MANAGER overrides that. BoxBuddy inherits the choice without ever mentioning it: get_container_runtime() in src/utils.rs makes the same guess for its own inspect/stats calls, and every distrobox list goes to whichever manager won the autodetection.
Two consequences on this machine, where both are installed:
distrobox list reports seven boxes, all podman's. DBX_CONTAINER_MANAGER=docker distrobox list prints just the header - no boxes. Had I created a box under docker, it would not appear in BoxBuddy at all, with nothing to suggest anything was missing.- Nothing in the interface says a box is a podman container rather than a docker one, even though that decides where its storage lives, which
podman/docker command acts on it, and whether it is rootless.
What I would like:
- Say which manager each box belongs to. A line on the box's page, next to the other facts about it. Only worth showing when more than one manager is installed - on a podman-only machine it would be noise.
- List boxes from every installed manager, tagged by manager, so a box created under the non-default one stops being invisible. Cheap enough: one
distrobox list per installed manager, and only when there is more than one.
- Choose the manager when creating a box -
DBX_CONTAINER_MANAGER=<manager> on that one invocation. This is the only "change it" that is actually possible.
On changing an existing box's manager: as far as I can tell it cannot be done, and I would rather the interface say so than offer a switch that quietly does nothing. A container lives in the storage of the manager that created it; there is no distrobox command to move one, and doing it by hand means exporting the image, importing it into the other manager and recreating the container - which is a different box with the same contents, not the same box moved. If that is wanted later, the honest shape is the one Clone Box already has: make a copy under the other manager and leave the original alone until the copy is known to work.
Happy to implement 1-3 if you agree with the split.
On a machine with both podman and docker installed, BoxBuddy silently shows only half the picture, and never says which half.
Distrobox picks its container manager by autodetection - podman first, then podman-launcher, then docker, then lilipod (
distrobox-list, lines 174-186) - and onlyDBX_CONTAINER_MANAGERoverrides that. BoxBuddy inherits the choice without ever mentioning it:get_container_runtime()in src/utils.rs makes the same guess for its owninspect/statscalls, and everydistrobox listgoes to whichever manager won the autodetection.Two consequences on this machine, where both are installed:
distrobox listreports seven boxes, all podman's.DBX_CONTAINER_MANAGER=docker distrobox listprints just the header - no boxes. Had I created a box under docker, it would not appear in BoxBuddy at all, with nothing to suggest anything was missing.podman/dockercommand acts on it, and whether it is rootless.What I would like:
distrobox listper installed manager, and only when there is more than one.DBX_CONTAINER_MANAGER=<manager>on that one invocation. This is the only "change it" that is actually possible.On changing an existing box's manager: as far as I can tell it cannot be done, and I would rather the interface say so than offer a switch that quietly does nothing. A container lives in the storage of the manager that created it; there is no distrobox command to move one, and doing it by hand means exporting the image, importing it into the other manager and recreating the container - which is a different box with the same contents, not the same box moved. If that is wanted later, the honest shape is the one Clone Box already has: make a copy under the other manager and leave the original alone until the copy is known to work.
Happy to implement 1-3 if you agree with the split.