I recently switched to Fedora Silverblue for my development machine. I want to document approximately how I do this (and why it’s awesome!).

Fedora Silverblue

This article is not an introduction to Fedora Silverblue, but a short summary is well-placed: Fedora Silverblue is an immutable operating system that upgrades atomically. Effectively, the root filesystem is mounted read-only, with the exception of /var, /home, and /etc. The system is upgraded by mounting a new read-only snapshot as the root filesystem.

There are three methods of installing software on Fedora Silverblue:

This article by Fedora Magazine goes into slightly more detail.

The basic development workflow

Instead of littering the base operating system with all means of development tools, development takes place within a toolbox. This looks a little like:

carmenbianca@thinkpad-x395 ~ $ ls
Elŝutoj  Labortablo  Nextcloud  Projektoj  Publike  Ŝablonoj
carmenbianca@thinkpad-x395 ~ $ toolbox create my-project
Created container: my-project
Enter with: toolbox enter my-project
carmenbianca@thinkpad-x395 ~ $ toolbox enter my-project
⬢[carmenbianca@toolbox ~]$
⬢[carmenbianca@toolbox ~]$ ls
Elŝutoj  Labortablo  Nextcloud  Projektoj  Publike  Ŝablonoj
⬢[carmenbianca@toolbox ~]$ # We're still in the same directory, which means
⬢[carmenbianca@toolbox ~]$ # that we still have our GPG and SSH keys, and
⬢[carmenbianca@toolbox ~]$ # other configuration files!
⬢[carmenbianca@toolbox ~]$
⬢[carmenbianca@toolbox ~]$ sudo dnf groupinstall "Development Tools"
[...]

The nice thing now is that you now have full freedom to mess with absolutely anything, carefree. If your program touches some files in /etc, you can mess with those files without affecting your operating system. If you want to test your program against a custom-built glibc, you can simply do that without fear of breaking your computer. At worst you’ll break the toolbox, from which you can easily recover by recreating it. And if you need more isolation from e.g. your home directory, you can do that inside of a non-toolbox Podman container.

The editor problem

There is a slight problem with the above workflow, however. Unless you install your code editor inside of the toolbox, the editor has no access to the development tools you’ve installed. Instead, the editor only has access to the tools that are available in the base system image, or the editor only has access to the tools in its Flatpak runtime.

There are several ways to get around this, but they’re dependent on the editor you use. I’ll document how I circumvented this problem.

VSCodium in a Flatpak

I use the Flatpak version of VSCodium. VSCodium has an integrated terminal emulator. Unfortunately the Flatpak shell is rather extremely barebones—it doesn’t even have vi! Fortunately, we can tell VSCodium that we want to run a different program as our shell. Change settings.json to include:

  [...]
  "terminal.integrated.shell.linux": "/usr/bin/env",
  "terminal.integrated.shellArgs.linux": [
    "--",
    "flatpak-spawn",
    "--host",
    "toolbox",
    "enter",
    "main-toolbox"
  ],
  [...]

main-toolbox here is an all-purpose toolbox that has heaps of tools installed. You can adjust these settings on a per-workspace or per-project level, so a given project might use a different toolbox than main-toolbox.

The way the above command works is a little roundabout. It breaks out of the flatpak and into the base installation using flatpak-spawn --host, and then enters a toolbox using toolbox enter. The end result is that you have an integrated terminal with a functional and feature-plenty shell.

This doesn’t solve everything, however. The editor itself also has some integration such as running tests. Because I mainly do Python development, it is fairly easy to bootstrap this functionality. The Flatpak runtime ships with Python 3.8. This means that I can create a Python 3.8 virtualenv and tell VSCodium to use this virtualenv for all of its Python stuff, which ends up working out just fine. The virtualenv is shared between the Flatpak and the toolbox, because both environments have access to the same file system.

For non-Python endeavours, Flatpak SDK extensions can be installed. This looks a little like:

$ flatpak install flathub org.freedesktop.Sdk.Extension.dotnet
$ flatpak install flathub org.freedesktop.Sdk.Extension.golang
$ FLATPAK_ENABLE_SDK_EXT=dotnet,golang flatpak run com.vscodium.codium

The final problem I ran into was using VSCodium to edit my Git commit messages. VSCodium has a tiny box in the UI where you can write commit messages, but it’s rather tiny and fiddly and not great. So instead I do git config --global --add core.editor 'codium --wait'. This should launch codium --wait path/to/git/commit/message when git commit is run, allow VSCodium to edit the message, and wait until the file is saved and exited to evaluate the message.

The problem is that codium only exists as an executable inside of the Flatpak. It does not exist in the toolbox or the base operating system.

I circumvented this problem by creating a custom script in .local/bin/codium. It tries to detect its current environment by checking whether a certain file exists, and tries to use that environment’s method of accessing the VSCodium Flatpak. This looks like:

#!/bin/bash

# Will still need to pass "--wait" to make it behave nicely.
# In order to get --wait to work in a Flatpak, run
# `flatpak override --user --env=TMPDIR=/var/tmp com.vscodium.codium`.

if [ -f /app/bin/codium ]
then
    exec /app/bin/codium "$@"
elif [ -f /usr/bin/codium ]
then
    exec /usr/bin/codium "$@"
elif [ -f /usr/bin/flatpak-spawn ]
then
    exec /usr/bin/flatpak-spawn --host flatpak run com.vscodium.codium "$@"
elif [ -f /usr/bin/flatpak ]
then
    exec /usr/bin/flatpak run com.vscodium.codium "$@"
else
    for arg do
        shift
        [ "$arg" = "--wait" ] && continue
        set -- "$@" "$arg"
    done
    exec vi "$@"
fi

This allows you to run codium [--wait] from anywhere and expect a functional editor to pop up. There’s a fallback to vi, which I’ve not yet hit.

I hope this helps anybody looking for solutions to these problems :) It’s more than a little bit of bother, but it’s incredibly reassuring to know that your operating system won’t ever break on you.