GNU Emacs 24 (released in June 2012) introduced official support for packages, that is, a way of installing extensions from a remote repository. This was a huge step forward for Emacs, as it not only allowed users to easily find and install extensions, but it also made it possible for extensions to build upon other extensions without having to tell the user “great you want to install this, just install this extensions and those five other ones, too.” It used to be that many extensions each re-implemented common functionality just to get around this problem. Now, we have a number of general-purpose libraries.
Two years into the age of packages, there are three (four) major package archives available, but they all have some serious problems, making none of them even remotely as useful as, say, Python’s PyPI.
GNU ELPA
Emacs comes with one package archive preconfigured, GNU’s own Emacs Lisp Package Archive (ELPA). This archive is subject to the same copyright assignment policy as Emacs itself, making it nothing more than a way of adding packages to Emacs without shipping them in the default installation. With a high hurdle (requesting copyright assignment not only from yourself but from any possible contributor) and almost no benefits, it’s hardly used.
At the time of this writing, GNU ELPA contains 74 packages.
MELPA
Arguably at the moment the most widely used package archive, MELPA follows a rather idiosyncratic approach to packages. Users do not upload packages, rather MELPA is configured with recipes that specify how to build a package from a remote source, ideally a version control system.
This solves one of the core problems of Emacs packages: Package authors quite regularly do not care about releases. Reducing the workload to get them published, as MELPA does, means there will be more packages available and they won’t become outdated easily just because the author did not feel like releasing their software again. This is a much bigger problem for Emacs Lisp packages than for other languages.
Sadly, MELPA has a few home-made problems.
By far the biggest one is the choice of version numbers. MELPA simply ignores any version numbers specified by the package and uses its own version number scheme based on dates. This makes sense, as it simply downloads the “latest version” from repositories, and for packages with no real releases, this isn’t a problem. But as soon as you have a package with actual releases, this is quite confusing. Worse, though, these version numbers act as a vendor lock-in. If your package ever gets on MELPA, you better keep it current there because whenever someone uses MELPA, their version will override whichever one you release because 20140613.420 is simply a higher version number than 5.1.3 or whatever you just released. And MELPA has no problems adding packages even without asking the author if they are ok with it, so authors end up having to deal with this problem no matter what.
And all of this completely without need. They could have just added the date at the end of any existing version string, and all would have been well. 5.1.3.20140613.420 is still higher than 5.1.3.
Even when you decide to support MELPA for a package with actual releases, it’s a pain. When you do a release, you can’t just go and announce it right away, because MELPA can take anything from an hour to a day to figure out that your source change and it re-builds it. You have no control whatsoever over this process.
Another problem is with the intention of MELPA. The maintainers deliberately want it to provide unstable packages, preferring unstable over even slightly outdated. Getting stable releases of packages with those into MELPA requires quite some effort and their authors have to deal with some abuse for it.
MELPA currently contains 1 834 packages.
MELPA Stable
To solve the latter problem, the MELPA maintainers created a spin-off of MELPA for stable packages. It has much stricter requirements than MELPA, and uses github tags to specify stable versions. This is a great idea, but sadly it’s primarily well-intended and does not actually solve any problem. Because it contains only roughly a third of the packages in MELPA unstable, users quite regularly have to use MELPA unstable as well. But MELPA unstable also contains the packages from MELPA stable, with the vendor lock-in version numbers, so they always override the stable ones, making MELPA stable mostly useless.
It is possible to circumvent this in Emacs 24.4 by pinning all packages available from MELPA stable to that repository, but that’s only possible in 24.4, and it’s something users need to do manually. Not really a good prospect for package authors.
MELPA Stable currently contains 591 packages.
Marmalade
Finally, there’s Maramalade. If you come from another programming language, this is what you expect a package archive to look like. Users create accounts, upload their packages with version numbers of their choice, and others can download them. Simple.
Sadly, it suffers from two distinct problems.
The first is the aforementioned mentality of many package authors. Uploading a package to a package archive is effort, and many simply skip it, much like they skip doing releases entirely. This results in a number of outdated packages in Marmalade.
The second problem is workload related. Marmalade used to be written in Node.js and was pretty flaky. The current maintainer had to rewrite it from scratch (it’s now a full web app written in Emacs Lisp, which is kind of cool), and he is already rather busy. With very little help, the rewrite took a while, and for a few months, uploads via the web interface were broken due to bugs in the old software, while currently, creating accounts is not working in the new software yet. Due to these problems, some packages simply moved away from Marmalade.
Between the heavy workload on the maintainer and the problems with package authors who do not do releases, I’m not sure about the future of Marmalade. Though I do hope it stays around; from the options we have, it’s by far the sanest.
Marmalade currently contains 1 043 packages.
Moving Forward
Emacs Lisp Package Archives have some rather unique problems to solve with the general reluctance to do actual releases of packages. Finding a balance between supporting this well and also supporting packages with actual releases is not easy, and all of the current archives have some serious problems because of this.
A good solution for this problem, and adapting or replacing the existing package archives, would be a huge step forward for Emacs.
