Already spent few days trying to make layered-vscode work with distrobox containers!
distrobox containers cannot be seen from vscode DevContainers out of the box in Bluefin-DX. There are some tricks available in the distrobox repo to make it work by placing a script, podman-host, under ~/.local/bin. Unfortunately, the connection to the VS Code server installed in real-time in the container aborts after few seconds because of conflicts either moving, linking, or renaming /var/tmp/.vscode-server inside the container.
Using podman by itself, by declaring it in Docker Path in the DevContainer extension settings, kind of partially works. It will login to the distrobox container as root, which is an inconvenient at the moment of creating or sharing files with the host. For instance, it will not allow you to save files modified in the container. The ideal scenario is being logged in as ${USER} inside the container.
I successfully have made ${USER} log in to the distrobox container via a flatpak-installed vscode along with the podman-host script mentioned above. But flatpak-vscode cannot find the docker executable anymore. You get that error that says you need to install Docker. I guess this is a side effect of flatpak-vscode not having all rights to access the system files.
There are other clues about accessing distrobox from vscode provided in one of the issues discussion. It involves adding a JSON configuration file under the ${XDG_CONFIG_HOME}/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs/ folder with the name of the distrobox.
If you continue digging, you find several proposed solutions out there: adding a container.conf file; symbolic linking to /var/tmp/.vscode-server; enable the docker service as a user; adding flatpak-spawn binary to the vscode folder; manually removing the folder /home/{USER}/.vscode-server; adding a devcontainer.json to the vscode project; and few more.
What this tells me if that we should work on creating a repeatable and reproducible set of instructions to be able to access all the awesome development capabilities of Fedora Silverblue derivatives. This guide should cover:
access Docker containers with Docker or Podman on projects available in the host
access Distrobox containers with layered or flatpak installed vscode
access to LXC containers from vscode or other similar editor
access to DevContainers, locally created, via layered or flatpak installed vscode
access Nix development environments via vscode or other similar code editors
access Docker containers with Docker or Podman on projects available in the host
You have a few options here. You can either use the docker-cli, name correct contexts, and use that use docker only options to talk with podman or docker. You need to make sure that you have access to the correct socket.
access Distrobox containers with layered or flatpak installed vscode
You will need to use Distrobox’s podman-host for this and now you are limited to talking to only podman containers. For the flatpak you need to install the podman-remote extension. The /var/tmp/.vscode-server method works and it’s an unfortunate hack that it is required. What’s better is using unique home’s per distrobox.
access to LXC containers from vscode or other similar editor
Use the ssh remote machines extension
access to DevContainers, locally created, via layered or flatpak installed vscode
Layered vscode, this works seamlessly with docker. With Podman you need to add the following run time argument --userns=keep-id. There is a lot of little ankle biters with dev containers, but most of the ecosystem is expecting the devcontainer to be using docker in a VM. Flatpak vscode you need to use the podman-remote tool or install the docker-cli inside the flatpak.
Honestly, there are a ton of ways to tackle development. The simplest method with vscode is to use docker with remote dev-containers. That’s what we have enabled by default in Bluefin/Aurora-dx