distrobox-export has no host-to-container direction
Edit: distrobox-host-exec(1) does document a way to do this - "you can symlink a command name to distrobox-host-exec and then call that command by its name" - which I missed when filing. So the mechanism exists; what is missing is the management around it. Narrowing the request accordingly.
distrobox-export moves things one way only: out of a container and onto the host (--app, --bin, with --list-apps, --list-binaries and --delete to manage them). For the other direction there is the symlink trick, and nothing else.
The difference in ergonomics between the two directions is the point:
| container -> host | host -> container | |
|---|---|---|
| create | distrobox-export --bin /usr/bin/foo |
symlink it yourself, in the right directory |
| list | --list-binaries |
nothing |
| remove | --delete |
rm, if you remember where you put it |
| marked as managed | # distrobox_binary in the wrapper |
nothing |
| where it goes | ~/.local/bin, or --export-path |
your problem |
That last row is not a small thing: the symlink has to be somewhere the container has on PATH and the host does not. The shared home fails that test, and the failure is a message saying the command was not run inside a container when it was (filed as #2207). /usr/local/bin inside the container works, but needs root there and is lost when the container is recreated.
What I would like
Something in the shape of the existing export, run inside the container:
distrobox-export --host-bin docker
distrobox-export --host-bin docker --delete
distrobox-export --list-host-binswriting the symlink or wrapper into a container-only path, marked with a comment the way --bin marks its wrappers, so it can be listed and removed like anything else distrobox put there.
Why it comes up
A container built for one job often needs a tool that belongs to the host and that the container should not own - in my case a development container driving the host's docker, with everything else about it isolated.
For docker specifically there is a neater answer that needs no bridge at all: with rootless docker, /run/user/$UID/docker.sock is already visible inside the container and owned by the same user, so pointing DOCKER_HOST at it is enough. That does not generalise to other host tools, which is why the export direction still seems worth having.
Version: distrobox 1.8.2.5, podman 5.8.4, Fedora 44.
Source: 89luca89/distrobox