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.


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?

  • 2
    See also: quelpa. The short answer is: Sure it is, there are still packages that are not on ELPA/MELPA/Marmalade. If you find that you need one, you can still get it without horrible hacks with el-get and the like.
    – PythonNut
    Commented Jun 9, 2015 at 21:22

4 Answers 4


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.

  • "if they didn't none would still bother to maintain them." The purpose may be only the developer's ego, though.
    – T. Verron
    Commented Jun 10, 2015 at 9:11
  • It'd be a mighty ego, though, that could easily attract as big a community as el-get still has, and QUELPA quickly gained :)
    – user227
    Commented Jun 10, 2015 at 9:24
  • I was commenting in general, of course. ;) For the specifics of the packages at hand, your answer, beyond the common sense statement, makes a strong point by exhibiting the purpose of el-get and quelpa.
    – T. Verron
    Commented Jun 10, 2015 at 10:10
  • @T.Verron Yep, point taken. I've removed that statement, it was a stupid thing to say. Sorry.
    – user227
    Commented Jun 10, 2015 at 10:36
  • @lunaryorn with el-get, however, does not expose its own packages to ELPA, meaning that **its packages** are entirely invisible to ELPA and ELPA you mean the things installed by el-get, right?
    – uuu
    Commented Aug 9, 2016 at 20:13

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 ;)

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.

  • I'm sorry that you had issues with Cask, but I do not think that your personal troubles and your apparent frustration with Cask bear any relevance to this question. Specifically, Cask is frontend to ELPA with a very narrow scope (mainly package development). While you can use it for package management, too, its conceptually orthogonal to el-get.
    – user227
    Commented Jun 10, 2015 at 8:46
  • In other words, Cask does not supersede el-get, nor does it aim to do. It's entirely unrelated. ELPA supersedes el-get. The best choice for Git-based installations isn't el-get anymore, it's QUELPA, and as I said in my answer, that's a valid reason to use QUELPA.
    – user227
    Commented Jun 10, 2015 at 8:51
  • 1
    I do agree about the narrow scope of Cask, don't get me wrong. Despite my "troubles" with Cask, I still use it on some Linux machines. I also don't have "git-only" packages, some of them are in mercurial or other version control systems. I also use packages from other people that will likely never be in MELPA or a git repository. My only point is that el-get is still ok when MELPA doesn't contain all the packages needed by someone. While I'm aware of QUELPA, el-get is good enough for me.
    – rimero
    Commented Jun 10, 2015 at 9:38
  • See, and and my point is that el-get specifically is not ok anymore nowadays, because it bypasses ELPA and Emacs' built-in dependency management, risking breakage and duplicate package installations. QUELPA provides the same features as el-get, but doesn't have this flaw. It's just better nowadays.
    – user227
    Commented Jun 10, 2015 at 10:42
  • @rimero I had the exact same experience. On top of that, I just tried Quelpa a few days ago, and had to drop it, at least for now. El-get seems still to be more flexible, powerful, and overall faster, at least for my use-case. I believe they embrace two quite different perspectives, so it may also depend on what kind of Emacs user one is. It would be adviseable to try both, before committing to one or the other.
    – gsl
    Commented Aug 1, 2015 at 15:59

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.