Writing my first Emacs package last month left me more cognizant of how Emac’s packaging system is put together and raised questions about how I use its capabilities. I had been installing all of my packages from MELPA, but now, as a fancy-schmancy package author I’d become intensely aware that MELPA builds its packages based on the latest commit in a project’s repository1. Suddenly I’d become paranoid about exactly what I pushed to the master branch of my project and worried about leaving things in a broken state.
Generally speaking, I keep the master branch on my projects in a functional state, and—yes—I could adopt a development methodology whereby work is always done on a development or feature branch and QA’d before being merged into master. But even if I have the inclination and discipline to manage my projects this way, all of my other Emacs packages are getting built from whatever happened to be pushed to master in their own project when the MELPA bot decided to make the rounds. I’ve run my fair share of beta software, but I don’t need every commit as it happens (cutting vs. bleeding edge).
As it turns out, there’s a new kid on the block—MELPA Stable—and she’s come to solve this exact problem.
MELPA Stable contains only stable versions of packages2. This means we’re getting new versions of packages when their maintainers feel that the version is ready to ship, rather than any time they make a change to their code.
Stable is also quite cleverly implemented, requiring only a single git tag in semver format to define a release. This not only makes life easy for package maintainers, but promoting semver is good for everyone (even end users!), because a consistent scheme for denoting version compatibility mean that developers can write more reliable software.
How to Switch to MELPA Stable
If you’re interested in taking the plunge—and don’t worry, it’s easy to switch back—the first thing to know is that not every package on MELPA is available via MELPA Stable3. If the package creator has not yet defined a stable release, the package will not appear on Stable. Before switching, you’ll probably want to think through the packages you consider critical to your Emacs workflow and type their names into the filter box on the MELPA Stable site to discover if they are available. It is possible to pull packages from two repositories but it’s not trivial and I won’t be covering it here.
Still with me? Let’s get started! The first step, naturally, is to open your
.emacs.d/init.el) and change your
package-archives form to look like this:
1 2 3
Now we’re set to fetch packages from MELPA Stable, but there are a few more steps to make sure your current set-up keeps on trucking:
If you don’t already have one, I’d recommend creating a list in your
.emacs file of packages that you use / always want installed. We can kickstart this process by first adding the following to the file:
With point after the
' character, type
C-0 M-: package-activated-list RET to insert a list of the currently activated packages:
You may see a few items in your list that you’re not familiar with—feel free to remove anything that you don’t recognize as something you use. They packages are likely to be dependencies of other packages that you use, and they will be automatically included as needed later on. Such packages might include things like
One “gotcha” of the upgrade process is that the faux version numbers MELPA generates (e.g.
20141116.1658) give the appearance of being higher versions than the proper version numbers from MELPA Stable (e.g.
0.2.0), thus if you have existing packages installed, the package system will never prefer the Stable version, believing that it’s outdated. To solve this you’ll want to delete all of your existing packages. This is easy:
Tell how to make the change in your .emacs / recover from package loading issues. Blow away directory. Reinstall. Maybe mention that you can’t use both at once.
Talk about my experiences (most everything available, unnecessary things not there, realized I don’t need color-theme anymore (though this current them is inferior), flagged all the ones that weren’t available to contact).
- idomenu – emailed author
Thank the awesome package mantainers and link to issues.
Include template for contacting them.
Actually the story is a bit more complex because MELPA recipes can pull code from a few different places (e.g. EmacsWiki), but pulling from Git master is probably the most common (and best) story.↩
With real version numbers, not the timestamp-style identifiers regular MELPA is forced to generate!↩
At the time of writing, 37% of MELPA packages are available via MELPA Stable (794 / 2148).↩