el-get installs Emacs Lisp from whatever source it happens to live in

The recipe is the abstraction, not the archive

el-get's pitch is that every package has a recipe, and the recipe is what tells el-get where the package actually lives. The README states that each recipe allows you to locate the original source and can be updated if the package is moved.

That single idea is what makes the tool different. The list of source types in the README includes github, emacswiki, GNU ELPA, Marmalade, privately hosted pages, git, bzr and CVS. No single one of those is the supported source. All of them are, because a recipe can describe any of them.

The argument the README makes against the alternatives is maintenance. Managing everything in a private git repository, or with `git submodules`, or by importing external repositories directly, all require manual upkeep, and especially so when packages come from a mix of locations. el-get's claim is a single interface over all of them.

The repository layout shows how little is hard-coded. Alongside the core files there are `recipes/` as its own directory, `methods/` as another, and `el-get-recipes.el` and `el-get-methods.el` tying them together. Adding a source type is a method; adding a package is a recipe.

What el-get does after installation is the part the README emphasises with emphasis. It will `require` the features you need, `load` the necessary files, set the *Info* paths so `C-h i` shows the documentation you now depend on, and finally call your own initialisation code.

Why running make and install-info is a feature, not a hack

The technical difference from `package.el` is stated directly in the README. el-get can run OS commands such as `make` or `ginstall-info` in order to cope with the diversity found in the wild, which allows for automatic inclusion of *Info* pages for packages providing some.

That is the whole argument in favour, and it deserves to be taken seriously rather than dismissed. An Emacs Lisp package is frequently not just elisp files: it has a texi manual that has to be compiled, a C extension that has to be built, a generated file. `package.el` installs from an archive of already-prepared elisp. el-get installs from a repository, and a repository often needs a build step.

The cost of that capability is that el-get needs an environment. The README states the installation requirements plainly: Emacs 24.5 and above, `git`, and an internet connection that allows `git clone`.

The `install-info` dependency is called out separately and is worth reading twice. El-Get depends on a working `install-info` command in your `PATH`. On Debian it is available in the `install-info` package. On macOS the Homebrew formula is the TexInfo one. On Windows the README warns that the way Emacs calls external programs differs between a native build and Cygwin, and that mixing them breaks: the Cygwin `install-info` errors out when called from a `windows-nt` Emacs, which the README notes you can inspect with `system-type`. For a native Windows build of Emacs it suggests the GNU Win 32 TexInfo distribution.

A package manager that shells out is a package manager with a build system, and the failure modes follow from that.

Installing without polluting your init file

There are two documented installation routes and the README is clear that they serve different purposes.

The lazy installer is for getting started. You paste this into a *scratch* buffer and evaluate it with `C-j` or `M-x eval-print-last-exp`:

(url-retrieve
 "https://raw.githubusercontent.com/dimitri/el-get/master/el-get-install.el"
 (lambda (s)
   (goto-char (point-max))
   (eval-print-last-sexp)))

The retrieved script clones el-get with git and installs it to `~/.emacs.d/el-get/el-get`. The README warns that this code requires an internet connection even if el-get is already installed, which is why it is advised for first-time installation and not for embedding in your `.emacs` or `user-init-file`.

The basic setup is what belongs in the init file. It detects whether el-get is already present and installs it if not:

(add-to-list 'load-path (expand-file-name "el-get/el-get" user-emacs-directory))

Where the snippet goes is also a decision. The README says to put it in your `user-init-file`, or in `early-init-file` on Emacs 27 and later, to avoid double-activation with packages installed by `package.el`. That is the coexistence problem in one sentence: if both package systems initialise the same library you get double side effects.

Adding `(el-get 'sync)` to the setup ensures that packages already marked installed get initialised and packages marked required get installed.

Replicating a package set across machines

The migration story is two forms and one command, and it is short enough to state exactly.

On the machine whose setup you want to copy, open an Emacs Lisp prompt with `M-x ielm` and evaluate:

`(setq my-packages
              ',(mapcar #'el-get-as-symbol
                        (el-get-list-package-names-with-status "installed")))

The backquote plus comma produces a quoted list of symbols naming every package whose status is installed. You copy that text into the other Emacs, where el-get should already be installed, and evaluate it followed by:

(el-get 'sync my-packages)

`sync` is what ties the list to the recipes, so the second machine ends up with the same set installed and initialised.

The asymmetry is worth noting. You replicate the list of package names, not the versions. Nothing in this procedure pins a commit, so the second machine resolves each recipe and gets whatever its source points at today. That is deliberate in a tool whose recipes are meant to be updatable, and it means a replicated setup is reproducible in membership but not in exact content.

If you need exact reproducibility, that is the wrong tool, and the README does not pretend otherwise.

Coexisting with package.el, and what the repository actually contains

The README has a section on El-Get, ELPA and package.el, and it concedes the ground rather than pretending el-get replaces anything.

Emacs 24 ships with `package.el`, which handles installation from several servers holding packaged extensions. The el-get position is that rather than asking authors or contributors to clean up and package existing software, el-get takes bits and pieces as they exist today. `package.el` is therefore supported as one of el-get's methods, and there is a specific function for the ELPA case, `el-get-elpa-build-local-recipes`, for installing extensions provided by ELPA.

Running two package managers in one Emacs is legitimate but needs care, and the double-activation warning in the setup section is the concrete symptom. The README points to a section called co-existing with package.el in the *Info* manual for the details.

The repository root lists what is actually shipped, and it is more than the core: `el-get-autoloading.el`, `el-get-build.el`, `el-get-bundle.el`, `el-get-byte-compile.el`, `el-get-check.el`, `el-get-core.el`, `el-get-custom.el`, `el-get-dependencies.el`, `el-get-install.el`, `el-get-list-packages.el`, `el-get-methods.el`, `el-get-notify.el`, `el-get-recipes.el`, `el-get-status.el`, `el-get.el`, plus `el-get.texi` and `el-get.info` for the manual and `test/` for the test suite. Documentation is written in Texinfo, which is also why the build depends on `install-info`.

On maintenance, the repository is not archived and the last push was on 2026-09-13, with a test workflow badge in the README. There are no GitHub releases, and the repository does not declare a licence in the metadata available here, which is a gap to check before vendoring it into a distribution.

Editorial conclusion

el-get fits an Emacs user whose package set spans git repositories, ELPA archives and older wiki-hosted code, and who wants C-h i to work for everything they install. It does not fit a setup that only uses one archive, since package.el covers that case with less machinery, and the run OS commands and shell out to git model is a poor fit for a locked-down environment. Verify first by pasting the lazy-installer snippet into a *scratch* buffer and letting it clone to ~/.emacs.d/el-get/el-get, because that path requires git, an internet connection and a working install-info on your PATH, none of which el-get can substitute for.

Frequently asked questions

Official sources

1. dimitri/el-get on GitHub
2. Issues
3. Project website
4. README