Introducing Powerline to Fedora Toolbox

First let’s setup a little baseline, a Powerline so to speak. I’m using Powerline as a plugin for my shell and for vim, a statusline tool turning the common shell line into somewhat useful with a bit more information than just the hostname, user and current path. It’s a great tool to pimp up my shell visually while showing me the current git branch I’m on, or if I’m inside a python environment.

My Powerline theme in action

What you see is that Powerline shows me my username, which is very hard to remember, the truncated path and current git branch because, well, I’m in a folder with a git repository. What you don’t see is that it would also show me the exit code of the last command, the python environment I’m in, or the job number of the last background command.

I’ve started to work on a new python project and wanted to try out Fedora Toolbox to manage the projects dependencies. Toolbox is a simple program using podman to create containerized environments where I can install development dependencies without cluttering my host machine. Pretty neat. Unfortunately I had two issues at first. The first one being that my custom flavour of Powerline apparently is not present in a default toolbox which is not much of a surprise. A simple dnf install powerline and applying source ~/.bashrc fixed that. The second one was a bit more involved.

Creating a toolbox is pretty straight forward. After you’ve installed toolbox with dnf install toolbox you can run toolbox create neat-tools and enter the toolbox in whatever cwd you like with toolbox enter neat-tools.

A broken shell due to missing dependencies

From python environments I’m used to Powerline showing me the python environment I’m currently in. After entering my new toolbox unfortunately I couldn’t tell from the statusline if my shell was inside the toolbox or not. You can guess that it’s hard to tell if an exit will throw me out of the toolbox or the entire shell. So apparently I had to introduce toolbox to my Powerline setup. Since there is no powerline-toolbox segment I decided to use the common.env.environment segment which allows me to show a text if a specified environment variable is present. With this I can add a little bit of logic to my .bashrc file that evaluates if the shell is loaded on a Fedora Workstation or inside a toolbox container.

    "function": "powerline.segments.common.env.environment",
    "args": {
        "variable": "POWERLINE_VIRTUAL_ENV_NAME"
    "priority": 50

Adding this segment configuration to a Powerline shell theme in e.g. ~/.config/powerline/themes/shell/some_nice_theme.json will create a bridge between Powerline and toolbox and now allows Powerline to be prepared if toolbox says hello.

# Load OS information and register variable for powerline
# to display special segment if user is within a container
source /etc/os-release
if [ "$VARIANT_ID" = "container" ]; then

I’m using the fact that /etc/os-release is different on Fedora Workstation and within a toolbox container. On Workstation VARIANT_ID is just workstation. If it’s a toolbox it’ll set the variable that I previously told Powerline about in the shell theme. With both the .bashrc logic and the addition to the Powerline theme I can now tell the difference again. Yay!

Powerline and toolbox finally know each other

What’s next?

Next I’ll probably build a toolbox container for my development workstation profile already including basic development tools, Powerline and the configurations to make it all work inside a toolbox. Who want’s to install all those dependencies for every toolbox again and again? Haha. Nice try! Stop trolling ;P

I already have an Ansible Workstation project that sets up all the dependencies I need. Using this deployment in a CI pipeline starting off from a toolbox container would give me a tailored, reproducible toolbox container as baseline for different requirements. I’m thrilled and looking forward to that!


Any thoughts of your own?

Feel free to raise a discussion with me on Mastodon or drop me an email.


The text of this post is licensed under the Attribution 4.0 International License (CC BY 4.0). You may Share or Adapt given the appropriate Credit.

Any source code in this post is licensed under the MIT license.