Emacs Package Versions and MELPA Stable
This is a bit of a rant. Hopefully, thought provoking, and absolutely not blaming anyone for anything. BLUF: I value a released version of Emacs packages, I choose to use MELPA Stable hoping the releases there are meaningful and reasonably stable in the sense that they don't change with every single commit, that they represent a point in time where the developer felt like putting a mark on the wall that certain features were “done enough” that users could upgrade (after all, its just a git tag command, so why not?).
A while back I rewrote my Emacs configuration1 with certain goals in mind. I won't rehash all of them, but one of them was to use only versioned packages as much as possible. That particular goal is still a fairly important aspect of my configuration. While I am a developer, I am not an Emacs contributor (yet.. maybe), so I use Emacs much like most of my tools. In other words, it's a tool. A fun, do everything, hacky kind of tool, but a tool to use to get things done. I want stable packages so my tool doesn't break and I waste time trying to figure out why it is broken and how to fix it.
Reading the GitHub page for the MELPA2 site, there is a section on MELPA-Stable. It has the following text near the bottom of that section, “Note that the MELPA maintainers do not use MELPA Stable themselves, and do not particularly recommend its use”. There are even several posts in different places3,4 which suggest not using MELPA Stable for different reasons: missing packages, lack of quality, lack of coordination between packages, etc.
Yet, I get messages from my installed version of lsp-java 3.1 which gives a warning indicating dash-functional is deprecated and please use dash-2.18! It actually recommends a version number! If you happen to be using MELPA, you'll likely never see this warning, and if you do, it's useless since the version number from MELPA is a timestamp. Unfortunately, there has not been a recent release of lsp-java which fixes the issue, so I'm still getting the warning. Seems to not hurt anything, but the solution is to stop using a released version lsp-java and instead switch to a development version.
Another user on reddit ran into a problem5 using a version from MELPA which broke his org agenda. He resolved the problem by providing a do-nothing defun. Comments indicated the code should have been guarded with conditionals and checks and things, but wasn't. These are the kinds of issues I'd like to avoid by using released versions.
Unfortunately, just tagging a package with a version number to get it to build in MELPA Stable provides no additional guarantees about quality or completeness. Which is one of the arguments to why you shouldn't use MELPA Stable. I'm not sure I completely agree with this, I believe the package maintainers are doing their best to provide quality software as best they can, and, at least in theory, they have performed a bit of testing to make sure their package works before they push their code. They are human and things get missed, mistakes happen etc, but why not release something periodically?
Consider this, if I add a dependency to my pom.xml for my Java project, I use a released version. If I install a package for my distribution of Linux6 I get a released version. I'm going to go out on a limb here and suggest it is at least uncommon, in general, for anyone to want a development version of a piece of software. Some absolutely do, and they should have the freedom to do so. However, that is exactly what MELPA users get! A development release, essentially whatever the developer checked in last when the MELPA build daemon ran. That isn't necessarily bad if you understand and desire the most bleeding edge package updates. If you don't though, then what?
Ideally, MELPA Stable would meet the following expectations:
- Slower updates, no expectation of a version update just because something was committed to master. Sometimes commits come in groups of changes around single concepts. But a new release when something is reasonably complete would be appreciated.
- Some amount of testing occurred to ensure the version is not likely to break something. Unit tests for the win, right! If unit tests are being written and they all pass after a change, why not make a release?
- New releases as dependencies change.
Most of this can be automated with tooling, ala GitHub Actions and similar, so the burden on the developer writing that amazing package, ideally, would not be high. Some initial investment, certainly, but long term those things which can be automated do help.
It would also help if Emacs' package.el were updated to support multiple versions among other things. There is currently no way to go back in time and choose to use a different version of an Emacs package using built-in tools. Indeed, there are a number of ToDo items listed in package.el and that list is likely not exhaustive.
There is a lot of technical work to improve the state of Emacs packages, which is significantly better today than it was a few years ago before we had package.el. Also, there are third party solutions like straight7 and others which solve the problems of versioning different ways. Personally, I hope the Emacs community can embrace MELPA Stable, or similar repositories (elpa.nongnu.org?) and give people like me a more reasonable choice to use released versions instead of development versions.
Tags: #emacs
Footnotes
1 https://jeffbowman.writeas.com/rewriting-my-emacs-config
2 https://github.com/melpa/melpa
3 https://www.reddit.com/r/emacs/comments/etikbz/speaking_as_a_package_maintainer_please_do_not/
4 http://blog.jorgenschaefer.de/2014/06/the-sorry-state-of-emacs-lisp-package.html
5 https://www.reddit.com/r/emacs/comments/qil2qh/symbols_function_definition_is_void/