Discussing better IDE integration (VSCode, etc...)

[Arcitec]

(This is labelled as a concept, which is an inprogress idea or proposal, it is not resourced or scoped so mostly just a collection of ideas. Over time it might move to a proposal)

We need to figure out how to connect VSCode to containers, set up devcontainers in podman, and all of that stuff.

I'm aware that some people install VSCode's GUI inside a distrobox and "export" the shortcut to the host, but apparently that has limitations with file permissions (according to a comment in the tracking ticket).

I am aware that VSCode as a Flatpak was terrible in the past (very limited), but I've been seeing recent articles where people happily use it via "remote container" extensions. Apparently it can run build tools inside podman containers very easily. If anyone's able to help with insights about that, please share your experiences regarding the setup and limitations of that.

It would be optimal if we're able to have a nice VSCode experience while running it as a Flatpak, rather than having to layer a native package or creating a distrobox.

The VSCode Flatpak definitely looks great. It is very actively maintained, 308 commits and has automatic updates of upstream and libraries:

https://github.com/flathub/com.visualstudio.code

Here are various articles about VSCode remote container solutions:

https://code.visualstudio.com/docs/devcontainers/containers

https://developers.redhat.com/articles/2023/02/14/remote-container-development-vs-code-and-podman

https://marketplace.visualstudio.com/search?term=containers&target=VSCode&category=All%20categories&sortBy=Relevance

This needs to be figured out, since a lot of people want VSCode, but we definitely can't layer VSCode natively in the main images, since only developers want IDEs. We therefore need to figure out the container workflow, so that we can write docs to help our users (and ourselves) use VSCode as a Flatpak, without natively layering it anymore.

As a high level summary, the way I understand it is that the container workflows are like this:

• VSCode runs as a Flatpak "on the host".
• You use some extension to connect to remote containers.
• Those containers can be on other servers, or can be local Podman containers, so it's super flexible.
• You install your dev tools and some vscode server component (maybe) inside the container.
• You then tell the Flatpak VSCode's "remote containers" extension to connect to that particular container. This should give you a shell, access to all build tools, etc.

There's definitely more to it, such as how to access local files... do they all have to be accessible from inside the container already, to be able to open them in VSCode when connected to a container?

And what would happen with the excellent "VSCode NeoVim" extension which uses neovim internally to support Vim motion in VSCode? That extension may not work in this workflow (if the "files" live remotely), which I'd be okay with though, since there's a few extensions that implement most of the important Vim motions natively in Javascript in VSCode instead: https://marketplace.visualstudio.com/search?term=vim&target=VSCode&category=All%20categories&sortBy=Relevance

[JohnAtl]

For me, VSCode was installed as a flatpak. Here's how I set it up.
And just to bring the info over here, when I ran code from the "host", it actually ran as root in the container, and files saved, git commits, etc. were owned by root. If I ran code from a prompt within the container, it ran as my user.

Running outside the container was motivated by being able to use my GPU for machine learning. This never worked out running code within a container.

[JohnAtl]

You were correct, it was installed in the container as well.
So the flatpak from outside ran as root, the user inside ran as 524288:524288.

[thatLeaflet]

This worked great for me, thanks. Didn't have any permissions issues.

[castrojo]

I'm taking a stab at playing with this with code layered + devcontainers and then a convenience tool like devbox or devpod.

[jibsaramnim]

Out of curiosity, does part of what you're playing with involve automatically installing a layered vscode package too? I was trying this out myself but it failed to install, presumably because /opt doesn't yet symlink to the expected path during this OCI image creation step — The same applies to 1Password, both of which needing to work together is actually the reason I'm still layering these two, as their Flatpak counterparts don't work together yet.

[dhassault]

Yesterday I tested the development in flutter. I couldn't get it access to Chrome yet. Otherwise having VSCode installed via Flatpak works after a bunch of tweaks (so container involved here).
I'm wondering in case of arduino and microcontrollers dev in general how it would work.

[Arcitec]

That's a good point: Code inside a Flatpak cannot access any processes running on the host or other Flatpaks. So that may be why it couldn't connect to Chrome.

But you may be able to manually open some http://localhost:[development port] in Chrome to view it anyway.

[colorfulmoth]

I've been testing multiple VS Code setups on my machine, and so far the one I find the least annoying is just using an Arch Distrobox and installing everything inside there. That includes my Slack, Postman, VS Code, Google Chrome, SDKs (Node.js, Flutter, Deno, python, etc). I don't really make use of my GPU since I don't do ML, but (maybe) an image that comes with stuff preinstalled could be a solution for some devs.

I also tested the flatpak and integrating it with that same Arch Distrobox, but it had some “fun” quirks like running as root inside the container, and after trying to figure out what was going on I just gave up. Perhaps someone else with more braincells than I can configure it easily, but I just couldn't.

[xynydev]

This is exactly my approach. I have an arch distrobox for all dev-needs, with all toolchains and compilers and interpreters installed, and VSCodium for code editing. Everything is integrated well because and most apps don't even know they're in a container or misfunction.

The only issue was with xdg-open not being able to open URLs I click in the terminal or VSCode, but that was easily fixed by creating a shell script called xdg-open in .local/bin that would use the hosts xdg-open if inside a container.

[dhassault]

Thanks for sharing this, super useful. I'm going to try it.

[AshleySchaeffer]

As requested by @castrojo; my setup revolves around using the VS Code flatpak on my base OS (Kinoite) where I then leverage the remote containers extension to develop inside distrobox containers, thus avoiding having many installations of VS Code within each development container.

However, while distrobox uses your base's user, the extension uses the root user by default. This means if you use the remote containers UI to connect to a running container it'll run as root, meaning anything you do in your homefolder (as mounted by distrobox) will get fubar permissions.

The devcontainer spec does accommodate a configurable remoteUser but I'm not using a devcontainer file per project in this setup. You can however, navigate to:

$HOME/.var/app/com.visualstudio.code/config/Code/User/globalStorage/ms-vscode-remote.remote-containers/

There you will find a few folders that contain devcontainer files made by VS Code from your usage of the remote containers GUI. The one of interest for me was imageConfigs, where devcontainer JSON files reside, named by the image and container name for each remote container you've connected to.

Adding a remoteUser key/value to the JSON spec and specifying your base OS user results in VS Code connecting to the container as that user, giving you the same distrobox experience from within VS Code:

{
	"remoteUser": "superman",
	"workspaceFolder": "/home/superman/foo",
	"extensions": [
		"bungcip.better-toml",
		"ms-vscode.cpptools",
		"rust-lang.rust-analyzer",
		"vadimcn.vscode-lldb",
		"VisualStudioExptTeam.intellicode-api-usage-examples",
		"VisualStudioExptTeam.vscodeintellicode"
	]
}

Unfortunately this option doesn't appear to be configurable anywhere in the VS Code settings. I'd also like to be able to ditch the proprietary VS Code build in favour of VSCodium but the remote containers extension prohibits this at present (another reason to move to neovim when I have the time I guess).

[AshleySchaeffer]

This workaround may require you to clear the contents of $HOME/.vscode-server/data/Machine or chown -R <user>:<user>. The extension appears to create some files (connection token and dev port) as the user it first connects with (root) so you end up with permissions issues after you've changed user.

[greenrd]

I've figured out a neat way to script the launch of podman containers on VS Code startup - like explainshell, which is a dependency of the Bash IDE extension. Incidentally, this technique should theoretically work for any Flatpak that has an extension/plugin installed within it that requires something else to be started - it's not limited to VS Code, or to containers.

Unfortunately I haven't yet figured out how to shut them down on VS Code shutdown yet, but it's something.

[lbssousa]

This is my approach for making devcontainers work with VSCode Flatpak + Podman:

1. In your project's devcontainer.json file, you must set properties remoteUser and containerUser properly. For example, if you use any base image from Microsoft itself, you must set both properties to vscode.

2. You must provide a file $HOME/.config/containers/containers.conf with the following contents:

[containers]
env = ["BUILDAH_FORMAT=docker"]
label = false
userns = "keep-id"

3. Download latest version of host-spawn and copy binary to folder $HOME/.var/app/com.visualstudio.code/data/node_modules/bin (don't forget to make it executable)
   3.1. In the near future, one can be able to install com.visualstudio.code.tool.host-spawn from Flathub. Add com.visualstudio.code.tool.host-spawn flathub/flathub#4267

4. Still within directory $HOME/.var/app/com.visualstudio.code/data/node_modules/bin, create a symlink to host-spawn named podman.

5. Set VSCode Dev Container extension option Docker path to podman.

6. Give your Flatpak write permission to /tmp folder:

flatpak override --filesystem=/tmp com.visualstudio.code

Previously posted at https://discussion.fedoraproject.org/t/vscode-devcontainers/45874

[lbssousa]

For attaching an existing Toolbx/Distrobox container to VSCode Flatpak, I use the following "classical" (I mean, not requiring a wrapper script for podman) approach:

1. Create a file ${HOME}/.var/app/com.visualstudio.code/config/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs/[your-container-name].json with the following contents:

{
  "remoteUser": "${localEnv:USER}",
  "settings": {
    "remote.containers.copyGitConfig": false,
    "remote.containers.gitCredentialHelperConfigLocation": "none",
    "terminal.integrated.profiles.linux": {
      "distrobox": {
        "path": "${localEnv:SHELL}",
        "args": [
          "-l"
        ]
      },
      "toolbx": {
        "path": "/usr/sbin/capsh",
        "args": [
          "--caps=",
          "--",
          "-c",
          "exec \"$@\"",
          "/bin/sh",
          "${localEnv:SHELL}",
          "-l"
        ]
      }
    },
    "terminal.integrated.defaultProfile.linux": "toolbx" // or "distrobox", if your container is a Distrobox one
  },
  "remoteEnv": {
    "COLORTERM": "${localEnv:COLORTERM}",
    "DBUS_SESSION_BUS_ADDRESS": "${localEnv:DBUS_SESSION_BUS_ADDRESS}",
    "DESKTOP_SESSION": "${localEnv:DESKTOP_SESSION}",
    "LANG": "${localEnv:LANG}",
    "TERM": "${localEnv:TERM}",
    "VTE_VERSION": "${localEnv:VTE_VERSION}",
    "XDG_CURRENT_DESKTOP": "${localEnv:XDG_CURRENT_DESKTOP}",
    "XDG_DATA_DIRS": "${localEnv:XDG_DATA_DIRS}",
    "XDG_MENU_PREFIX": "${localEnv:XDG_MENU_PREFIX}",
    "XDG_RUNTIME_DIR": "${localEnv:XDG_RUNTIME_DIR}",
    "XDG_SESSION_DESKTOP": "${localEnv:XDG_SESSION_DESKTOP}",
    "XDG_SESSION_TYPE": "${localEnv:XDG_SESSION_TYPE}"
  }
}

2. Follow steps 3 to 5 above.

PLEASE NOTE: when setting remoteEnv, you may need to set variables SHELL, SSH_AUTH_SOCK and DISPLAY as well, but they may be overriden by VSCode Flatpak. If you need these variables properly set, take care to set these values from host system, not from VSCode Flatpak. For example, you can run

flatpak --user --override --env HOST_DISPLAY="$DISPLAY" --env HOST_SHELL="$SHELL" --env HOST_SSH_AUTH_SOCK="$SSH_AUTH_SOCK" com.visualsudio.code

and then set the remoteEnv section as follows:

"remoteEnv": {
  "DISPLAY": "${localEnv:HOST_DISPLAY}",
  "SHELL": "${localEnv:HOST_SHELL}",
  "SSH_AUTH_SOCK": "${localEnv:HOST_SSH_AUTH_SOCK}",
  ...
}

3. [OPTIONAL] If you don't want to leak directory .vscode-server from container to your host-system home folder, create a directory /.vscode-server within it (with write permission to your normal user), and create a symlink ~/.vscode-server pointing to /.vscode-server.

[xynydev]

My approach nowadays is installing and configuring all shell bling and code editors with home-manager.
Programs from Nix are accessible in both the host and Distroboxes, and launching VSCode(ium) from inside of the box makes it's integrated shell environment also exist within that box.