Package Management in Emacs

I have been using Emacs for quite some time, and in general for everything. Although the number of elisp packages distributed along with this text processor is constantly growing, sometimes you still have to install third-party packages. Over time, their number is also gradually increasing, they have to track dependencies, they also need (or desirable) to update, in general, the standard set of tasks for the package manager. Until recently, to install elisp-packages I used system-package-managers under linux of type apt, portage. Of course, there were some inconveniences, but the real problems started when Emacs had to be used under Windows and Mac OS. In addition to the package management itself, there is a need to synchronize all installed files, not just the settings in ~ / .emacs.

As a result, I matured to use a full-fledged manager of elisp-packages, preferably with the following qualities:

• large package base
• convenience of creating and maintaining your own packages
• ease of synchronization of installed packages between computers
• cross-platform without installing additional applications

After a little research of the existing possibilities, this review turned out, in which I will dwell on elpa and el-get in detail, and also briefly tell you about the others.
')


Important note: everything described below has been tried on a stable version of emacs 23, earlier versions may not work as described. Special testing on different operating systems was not carried out, some trivialities were found out in the course of operation.

ELPA or package.el

Initially, the Emacs Lisp Package Archive (this is how elpa stands for) was located here , the original can still be downloaded and installed. Currently, package.el is supported in the emacs development tree and will be included in release 24. That is, elpa will potentially have a large user base, so the package base will evolve. By the way, it is included in the Emacs Starter Kit , this is probably the easiest way to install elpa for beginners, plus it works with emacs 22, but for my purposes there are too many unnecessary ones. It is much easier to take package.el from the emacs development tree, I recommend this version, because after it package.el ceased to be completely independent.

So, create a folder ~ / .emacs.d / elpa to store all installed packages, put the downloaded file there and add the following lines to ~ / .emacs:

;;; This was installed by package-install.el.
;;; Move this code earlier if you want to reference packages in your .emacs.
(when (load (expand-file-name "~/.emacs.d/elpa/package.el"))
(package-initialize))


After executing this command (or, at worst, restarting emacs), you can try Mx list-packages to get and view a list of packages from the database. By default, http://elpa.gnu.org is used, there are quite a few packages there, so we will add repositories:

;; use more repositories for elpa
(setq package-archives '(("elpa" . "http://tromey.com/elpa/")
("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")))


Pros:

• guaranteed support in upcoming emacs versions;
• absolutely cross-platform, pure elisp;
• centralized repositories make it easy to find and test new packages;
• A good interface for searching and viewing packages.

Minuses:

• there is little additional information about (not) installed packages: there is no installation date, there is no repository name, there is still a lot of things;
• does not support the list of installed packages, it makes it difficult to synchronize packages on different machines;
• can not remove packages and dependencies;

To date, there are about 330 packages in the repositories, a couple of months ago there were about 280, progress is evident.

el-get.el

You can find it on GitHub 'e (where else?), Where the author also suggests the Emacs Kicker as an alternative to the Emacs Starter Kit. You can install el-get as well as elpa by executing just one command that downloads the installation script, clones the repository from github into ~ / .emacs.d / el-get and initializes it. Since ~ / .emacs.d is already under the supervision of git, I used the git submodule:

cd ~
mkdir .emacs.d/el-get
git submodule add github.com/dimitri/el-get.git .emacs.d/el-get/el-get


This will make it easy to update both the manager and the package database ( recipes ). All packages from recipes are installed in ~ / .emacs.d / el-get and do not mix with elpa packages. To get started, you need to add the following to ~ / .emacs:

;;; check if git sumbodule is there before loading el-get
(when (file-readable-file "~/.emacs.d/el-get/el-get/el-get.el")
(add-to-list 'load-path "~/.emacs.d/el-get/el-get")
(require 'el-get)
;; packages to manage
(setq el-get-sources
'((:name magit :type elpa)
))
(setq recipes
(append
'(bbdb mediawiki auctex)
(mapcar 'el-get-source-name el-get-sources)))
(el-get 'sync recipes))


After downloading, the el-get code checks the installed packages and, if any are missing, tries to install them. So el-get, bbdb, mediawiki and auctex are set from your own recipes, and magit using elpa. Besides installation from apt-get, git and any other is possible. At the same time, elpa and apt-get install packages into separate folders and, in principle, can manage their packages independently. This is not recommended, since el-get creates symlink'i in its directory, and if the package is removed from the outside, it will be unpleasant. In general, the list and options of installed packages are best kept in one place as shown above, this greatly simplifies synchronization between computers.

Recipes can also be set interactively using Mx el-get-install, while the truth can get into a trap: already installed packages are not displayed in the list of auto-completion, and therefore a false impression may appear that they are not in the database. This is another reason to keep a list of packages explicitly.

Speaking of sync. To install everything you need in a new place, it is enough for me to run a couple of commands before running emacs:

cd ~
git submodule init
git submodule update


After (re-) running emacs, everything will be installed automatically. True, there are several pitfalls:

1. If additional programs are needed to compile a package other than emacs, they will have to be installed and made to work. As an example, I’ll give emacs-w3m: it requires cvs to download the sources and autoconf to compile. Honestly, I couldn’t get emacs-w3m to work under Windows.
2. If apt-get is used, then under Linux the package can be installed only on debian derivatives, on Mac OS you can use Fink (el-get supports it too), but this is for the amateur. Plus, you need administrator rights, since such a package is installed in the system.
3. Using symlinks with third-party package managers makes life difficult under Windows XP, they are not supported there. Although the unstable branch seems to be fixed, but I have not tried it yet.

Pros:

• keeps a list of installed packages;
• can remove packages;
• working with third-party package managers, starting from version 2.2, all manipulations with elpa are no longer necessary, because el-get includes an adapted version;
• in principle, cross-platform (see pitfalls above);
• being actively developed.

Minuses:

• does not track versions at all;
• very inconvenient interface: the names of the packages from the recipes can be viewed using autocompletion, you can request additional info on el-get-describe, but there is no nice list with a description like in elpa.

About 350 packets were found in the recipes, adding elpa packets, we get quite a beautiful number. In principle, it is able to install packages from emacswiki , and this is about 1660 packages.

Rest

I looked through all the other package managers quite fluently, the list of managers and additional information can be found on EmacsWiki and StackOverflow .

• auto-install : Uses emacswiki as a centralized package base (other options are also possible), can track dependencies and show differences between versions. Can be installed from el-get.
• elinstall.el : Not very clear documentation.
• epackage : Must become a Distributed Emacs Lisp Package System (DELPS), storing and distributing packages is used by git. the idea may be good, but I don’t smile to keep the whole tree on the disk because of a couple dozen packages. In general, the development is somehow sluggish.
• epkg.el : Also uses git, half a year in development, not yet plugged.
• install.el : Apparently no longer supported, the last date in copyright is 2006.
• install-elisp.el : predecessor of auto-install , no longer supported
• jem-pkg.el : Of interesting chips, it supports different configurations for different machines, although I just need to maintain the same packages and settings for all computers. And it's not clear where to get the packages from.
• pases.el : Packages are made as Makefiles, they need to be compiled (manually?), and pases will install them into emacs. There are very few packages, in general it looks like a student’s thesis.
• pelm : PHP Emacs Lisp Manager, true emacs' fetters are indignant.
• plugin.el and use-package.el are no longer supported.

Instead of concluding, I note that at the moment I use the above described combination of el-get + elpa. When the time comes, I think to play around with auto-install and tell the habra social community about it.