Austin Hunter

Snap (and tunnel vision) = Headache

Author: Austin Hunter

Published: April 9, 2025

I’ve been using Ubuntu as my primary OS for nearly 5 years. Up to this point, I didn’t see a big issue with Snap. Sure, I’m not a fan of proprietary software being used to manage the (primarily) FOSS software that I use daily, but sometimes convenience wins out - but sometimes it doesn’t. Today was one of those days where convience came back to bite me. I was sitting down to work on my new blog (the one you’re reading this on) and I went to open the project up in Neovim when I saw that there were updates for some of my plugins (I use Lazy to manage plugins). I decided to install the updates and expected everything to go smoothly, like it normally does. When I opened a file and started trying to edit it, I noticed a problem; my autocomplete plugin had stopped working. Weird. I decided to simply restart Neovim, as this can occasionally help to get things working if something funky happens after an update. I had hoped things would go back to normal…

A Bigger Problem

I was greeted by the following error output after restarting Neovim. Neovim error output So things hadn’t gone back to normal, but that’s ok, it should be a quick fix. I scanned the error output and saw that the issue was coming from my build of Frizbee, which is a Rust fuzzy matcher that Blink uses, and that the error has something to do with glibc. The answer seemed simple - I’ll just go check the Blink GitHub repo and see what changed, if that doesn’t work, I’ll check the Frizbee GitHub repo, the answer must be in one of them. Wrong! Nothing there helped point me in the right direction. That’s ok though, surely I’ll be able to find the answer if I just google it. Also wrong!

Why am I getting a mismatch between glibc versions? That’s what I was looking into since there was no documentation to point me in the right direction. Finally, I quit googling long enough to look back at the error. Then I saw it, the path of the mismatched file - /snap/.... Keep in mind, I had completely forgotten that I had installed Neovim with Snap - I rarely use Snap, so why would I use it to download Neovim? I really don’t know.

The root of the problem

If you’re not familiar with how Snap works, it essentially creates a stable environment for you applications, including maintaining its own copies of the GNU C libaries that keeps your Linux system running as expected. What this means, is that the binary for Fuzzy was being built against one target (the host machine) and run against another (the Snap environment). This is the sources of the mismatch.

The fix

I decided to just go ahead and install Neovim on my host machine, like I should have in the first place, but doing this would require me to manually update Neovim any time I want to upgrade to a new version, which would be a minor inconvenience, and nobody likes those. Then I stumbled across bob A lightweight version manager for Neovim. This makes it easy to install new versions and/or switch versions of Neovim on the fly.

With the Neovim Snap package removed and Neovim re-installed on my system, I opened Neovim up and everything worked as expected.

Concluding Thoughts/TL;DR

I’m starting to understand the practical reasons that cause people to dislike Snap. keeping things in an isolated environment might work well for apps with little to no configurability, but if an application is extensible enough that you might be building additional static libraries used by the application, then you should just install the software on your host machine outside of the Snap environment.

TIP

Try not to forget when you use Snap to install software, remembering this detail will prevent headaches in the future!

Overall, this was a very quick and easy fix. The headache of fixing it was entirely of my own making by forgetting I installed Neovim with Snap and getting tunnel vision when debugging the code. If I had double checked the error sooner, I could have saved myself about half an hour of trouble shooting.