One of the thing’s I’ve been thinking about recently is package management for my emacs customizations. I have a large number of emacs packages that are at least intrinsically external to my own repository - 42, I believe - and I have to install Emacs on a new system roughly once every four months. When I recently switched from SVN to HG for hosting my repository, this prompted me to think a lot about how to organize it, and this problem in particular.
Unfortunately, this seems to be a nontrivial problem. The easiest solution would be for all of these packages to be added to emacs core; this is rather unfortunately not going to happen. The three main possible solutions I thought of are the following:
The first option, which I did for a long time, is to just check each package into your emacs customizations repository. This overall is a decent solution; it’s probably what most people use. It has the advantage of making your repository stand-alone - nothing but it has to be checked out. However, it makes it difficult to detect updates to packages you use and to apply those updates. This tends to end up with you having fewer features and more bugs than you otherwise could have, which lead me in search of other solutions.
Option #2 - Hand-rolled package management
The solution I currently have in-place is a set of utilities that will download the latest version of a library if it exists. While this does mostly solve the problem of difficult updates(at the time of a fresh Emacs install, I am fully up-to-date, and can juts use native VC to update further), it introduces a new set of problems. For one, it makes the repository not be packaged together, making it harder to distribute to others. It also requires installing a lot of different version control systems - I think the various modes I need to check out use six different ones. Finally, there are cases when I don’t want the latest version, or need to apply a patch, because it is broken.
The only one of these problems I currently solve is the last one. My repository contains a directory with modes that can’t be managed by the utilities I described above. This can be because they are hard to download pragmatically or the latest version is broken - clojure-mode is an example of the latter, member-functions.el the former. This is essentially Option #1 on a slightly smaller scale.
Option #3 - ELPA
What I’d really like is a finished ELPA, included in a base Emacs distribution. ELPA is the Emacs Lisp Package Archive, a package manager for Emacs, slated for addition to Emacs 24. I’ve tried it, and while it’s a good idea, right now it is not good enough to use - hopefully, this can be fixed, because it seems like this would be a solution to most of my issues. However, right now, there’s the following reasons I don’t currently use it:
- Ease of upload - This only seems like it should be an issue for package developers, and thus not affect my use of it in my repository, but I think it’s one reason for later items. Essentially, if it’s hard to upload a new package to ELPA, more package maintainers will just not bother doing so. Right now, the process seems to be to email the package to the ELPA maintainer, who will put it in or update the package, which is clearly not scalable or particularly easy. Ideally, I would be able to register some version control location with ELPA, and have it pick up any changes I make to it.
- Requirements for packages - The packages included must meet some irritating requirements, with comments in specific formats and other issues. These aren’t too bad - ELPA needs some way of finding dependencies and requirements - but it also doesn’t support multi-file packages very well. This is a fairly big issue, since without this it can only be used for smaller modes.
- Availability of packages - Right now, fewer than 10% of the packages I use are in ELPA. This is a combination of reasons, such as some packages being old, some not meeting the requirements described below, or the developer is just lazy. Whatever the reason, I’d like it to contain more of the packages I personally use, although I’d be willing to help convince others to put their packages on ELPA if my other problems were solved.
- Old package versions - Some of the package versions on ELPA, such as eproject, are quite old. I suspect this relates to issue #1 above.
- No update/revert mechanism - Once you’ve installed a package, there’s no way to update it if ELPA receives an update. There also isn’t a way to revert to a previous deployment.
For now, I don’t really have a good solution. Hopefully, ELPA will improve - I may work on that some myself - but in the meantime, if you have your own system for managing external packages, please let me know in the comments.