The infragility of emacs packages
09 Dec 2025
Irreal recently published a post about the debate between using external packages in emacs and sticking to built in stuff or writing your own functions. I’ve also noticed that in the emacs community a lot of people seem to hold using the base packages in higher esteem than external ones. And i also think that this is not necessarily the right mindset—there are many external packages that really improve the value of emacs. But one quote in particular stuck out to me:
There’s a point to made in his favor. In the open software realm—if not in the Emacs world—there are lots of libraries full of trivial functions that are easily implemented in a line or two. That can and has caused problems when the author withdraws the software or a library gets contaminated with malware. That, of course, is the theme of this famous xkcd comic. To some extent those problems are unavoidable but why subject yourself to them to get access to a trivial function?
The danger of relying on external packages, so it goes, is that often those packages are maintained by one person who can pull the plug at any time. It’s true, there’s always a danger of someone removing a package from its online home. But i think that this is less of a concern with emacs than with other some other software.
First, when i download a package, it is stored in my emacs directory. At its core, all the emacs package system does is automatically adds a subdirectory to my load path. There is no fundamental difference between having vertico stored in elpa/vertico-20251115.1826/vertico.el and site-lisp/vertico.el. If the package disappeared from the internet, i still have my local copy.
Second, there are projects like the emacs mirror that aim to act as a second location for emacs packages, so that if they become unmaintained or go offline, they are still available to download, in the case that you didn’t have a copy already downloaded on your computer.
One concern people have about relying on these external packages is that in the event that they do eventually end up unmaintained, they will have to start fixing the package themselves, or otherwise change their workflow. This is where emacs particularly shines, because unlike other some other software that seems to change every time i update it, emacs has an excellent track record for backwards compatibility. Multiple times i’ve been able to download something from the emacs wiki that was last updated fifteen or twenty years ago, and it runs just fine. Sometimes there is a deprecation warning, but these can be ignored if i’m okay with some annoying messages in the echo area.
If a workflow works for me, i can rest easy knowing that within emacs, it’s going to work forever.