What are the use cases of alternative package managers vis-à-vis `package.el`?

Question

Background

I use emacs daily, but mostly to get things done. I don't really like customising it more than adding packages and I don't like troubleshooting. I want emacs to fade into the background the way a good OS does and just get on with things. A while ago I found that el-get allowed me to install the packages that I needed which were unavailable with package.el and also gave me more control such as selecting the maint branch of Org-mode rather than the bleeding edge which can cause temporary problems. Now I'm not sure if I should be using el-get or not.

Question

el-get seemed to be a great solution to the various repositories and emacs hacks out there. It offered capabilities which were simply not possible with package.el. Now that package.el in newer versions of emacs (>=24.4) supports multiple repositories, what are the use cases for el-get and similar alternatives to emacs's built-in package manager?

Answer 1

There are things that are still impossible with ELPA, and there are things that will always be impossible with ELPA, because they do not fit into the concept of ELPA: You'll never be able to install a specific commit by its hash from a forked repository. Likewise, you'll never be able to apply custom local patches to a package before installing it. These features are simply beyond the scope of ELPA, and if you need them, you'll have to use an alternative package manager.

I think, though, that el-get is kind of a legacy solution nowadays. Given that ELPA has become the de-facto standard package manager for Emacs, alternative packages managers should seamlessly integrate with ELPA. el-get, however, does not expose its own packages to ELPA, meaning that its packages are entirely invisible to ELPA and ELPA packages can never depend on el-get packages, with obvious implications for dependency management.

If you need features beyond ELPA, you should nowaday look at QUELPA rather than el-get.

Answer 2

I have written a new package manager for Emacs, straight.el, which attempts to improve on all existing package management solutions. There is an extensive section in the straight.el documentation about comparisons to other package managers, but here is a very short summary:

• package.el downloads opaque tarballs from central servers, with no option for selecting a specific version of a package, and doesn't allow you to make local changes to your packages; contributing changes upstream is impossible. straight.el clones Git repositories in a decentralized way (but it automatically uses recipes from MELPA, GNU ELPA, and EmacsMirror, if you wish), and allows you to make arbitrary local changes to them, commit those changes, and contribute upstream. This can be done manually, or you can use the built-in bulk repository management operations. Changes to your packages are detected automatically, and manual rebuilds are not required. Furthermore, straight.el supports complete reproducibility for your Emacs configuration, since it allows you to write a revision lockfile that includes the Git hashes of all of your packages.
• Quelpa and Cask are both based on package.el, and inherit many of the same disadvantages. For example, Cask does not have any concept of installing a particular version of a package. Quelpa does, but it requires that you hardcode the Git hash into your init-file. straight.el eschews package.el entirely, replacing all of its core functionality with a unified design tailored to many more use cases.
• el-get has the advantage that you can install packages from absolutely everywhere (all known version-control systems, arbitrary HTTP, system package managers, EmacsWiki, even go get!?). However, by supporting so many sources, el-get cannot provide the kind of advanced package management operations (such as reproducibility through revision lockfiles and interactive repository management operations) that straight.el provides. straight.el only supports Git, since most packages are available through Git and the ones which are not can be obtained via the EmacsMirror (I dare you to find one that cannot be!). Note that straight.el nevertheless provides an extensible API for additional version-control backends (e.g. for Mercurial) to be added in future, if desired.
• Borg has a very similar philosophy to straight.el and gives many of the same advantages. However, it is not designed to be a full package manager, and is designed to be used in concern with other tools such as epkg, auto-compile, and Magit. On the contrary, straight.el is self-contained and provides everything you need by itself, requiring little to no additional configuration. Also, Borg uses Git submodules, whose interface has some rough edges, whereas straight.el uses independently managed Git repositories, yielding additional flexibility and power.
• There's also the manual approach, but I don't recommend this. After the first couple of months, you would have reinvented Borg. Then after the next couple of months, you would have reinvented straight.el. You'll learn a lot about package management, though ;)

Answer 3

While there are pros and cons, I think that el-get is still relevant, despite the strong opinions of @lunaryon (rejeep too).

I used raw package.el with use-package for a while (2 to 3 years), then switched to el-get, then Cask. I went back to el-get few days ago. Prior package.el, like many others, I was manually handling add-ons.

Why did I go back to el-get? I encountered some Cask weirdness about something not being a git repo (a Github package of mine which is not in MELPA), while that package is actually using git... I didn't bother investigating or creating a ticket, just pulled my old el-get config and I was good to go in no time.

Few things that I like about el-get:

• It supports multiple fetchers, not just git.
• It contains enough pre-defined recipes
• Faster than Cask on startup.
• and yes @lunaryorn, the Wiki is not a place to distribute code, still I don't want to create a Github repo if there's no clone on emacsmirror (Github).
• Self contained, with Cask you need an external installation. I use a single init file(not a modular configuration) with allout-mode to navigate through sections.
• el-get is simple enough from a user perspective.

Note: I'm running Emacs Git HEAD under OSX and Linux.

Answer 4

You might want to have a look at paradox. It's not another package manager, but a neater front end for package.el. For example, when you update packages, it asks whether you want to install them and delete the old ones in one step.

If you use it, you probably want to set paradox-execute-asynchronously to t in your init file.