Emacs Stack Exchange is a question and answer site for those using, extending or developing Emacs. It only takes a minute to sign up.
Sign up to join this community
I notice that there are several different repositories that often contain the same software. Why would I want to prefer:
over the others? Since any one repository does not contain all the packages that I want, is it a good idea to have these repositories enabled simultaneously?
GNU ELPA is the official GNU Emacs package repository. It's the only one enabled by default, which means that it has the greatest reach. At the same time, submitting a package there is a bit of a hassle and requires an FSF copyright assignment, which means it has a relatively limited selection of packages.
MELPA and Marmalade are both third-party package repositories. They're not officially supported by GNU, but also have much larger selections of packages. Package quality is a bit more variable, but you're much more likely to find whatever you're looking for, especially if it's a bit obscure.
Marmalade and MELPA have slightly different models for package uploaders. My understanding is that MELPA tracks a version control repository directly (ie via GitHub), letting package authors update packages just by pushing commits to a branch. Marmalade, on the other hand, has people upload packages to the repository explicitly.
In practice, I haven't seen much difference between MELPA and Marmalade. There isn't much downside to enabling both of them to have the largest possible selection of installable packages: I've been using both (and GNU ELPA, of course) for a while with no significant problems.
One possible concern (which I haven't run into myself) with having both repositories enabled, which I haven't run into myself, is having packages available from both at different versions. By default, the package manager (package.el) does not have any way to resolve conflict like this; however, you can resolve this by installing the melpa package which lets you customize which packages are provided or excluded from which repositories. You can see more details here or from the documentation for the melpa package.
As @Malabarba helpfully pointed out, this problem is resolved in Emacs 24.4.
If you're really worried about security, you may want to avoid both MELPA and Marmalade because they let anyone upload packages and, as far as I know, don't have any proactive security arrangements. The GNU ELPA repository, on the other hand, is managed by the FSF and has signed packages which should help. Of course, if security is really important, you might want to just review and install elisp packages by hand instead of using the package manager.
The way I think of it, some repos have more overhead involved with submitting packages than others; the repos with more overhead tend to have fewer packages. In order from most to least overhead:
Personally I think either MELPA Stable or Marmalade will probably win out in the long run for most users—MELPA proper is pretty unstable and ELPA is too restrictive to be really scalable for lots of packages. But that's just an opinion.
There are several package repositories available.
Official
GNU ELPA is the official package repo. It's small, and requires copyright assignment (of all authors of a package) to the FSF to contribute to it.
Packages on GNU ELPA are really just a git repo. The advantage of being hosted here is that the core team try to update packages if Emacs itself adds or deprecates features.
Built from source
MELPA is the biggest and fastest growing package repo. It releases a new version every time a new version is pushed to a repo, or an EmacsWiki page is updated.
It's bleeding edge, but it works very well in practice. MELPA is curated to avoid duplicate packages, and to ensure that the canonical home of package is recorded (instead of a random fork).
MELPA does have the problem that versions are just timestamps, e.g. my-package-20131231.2359. This means if you depend on my-package:
;; Package-Requires: ((my-package "1.2.3"))
then Emacs will think that any version on MELPA is new enough.
MELPA Stable is the same as MELPA, but rather than using datestamp versions, it uses the versions in git tags. This allows for better dependency resolution, but has issues with depending on wiki packages.
User uploads
Marmalade is much more like a traditional repository from other programming languages. The package developer uploads the package to Marmalade when they do a release.
In principle, this gives packages a proper release process (Marmalade predates MELPA stable) and also avoid the autogenerated version number problem. However, there's no identity verification. Anyone can upload a package, even if they didn't write it. This gets difficult if the maintainer of my-package finds that someone else uploaded my-package and can't subsequently upload new versions.
Marmalade used to be a node.js app, and it's now written in elisp. Both versions have had uptime problems occasionally.
Project-specific
Org-mode ELPA is a repo that only hosts org and org-plus-contrib. Org-mode is part of Emacs core, but it's developed externally and the code is only synced with Emacs trunk periodically. This repo lets you have the bleeding-edge org-mode.
User42 ELPA is a repo for a single package developer who has released quite a range of Emacs packages. If you like any of his packages, you could add this repo.
Sunrise Commander ELPA is a repo for extensions for Sunrise Commander (an Emacs package for file browsing, inspired by midnight commander).
Retired
Tromey's ELPA was the first repo set up. It is officially replaced with GNU ELPA, but it didn't have the same copyright assignment requirements. As of 2010, it is no longer updated.
Elpy package archive contained various packages developed by Jorgen Schaefer for 'Elpy, the Emacs Python Development Environment', but that has migrated to MELPA Stable.
no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: but I'm sure those concerns will disappear now that it's Microsoft GitHub ;-)
Some additional info, to supplement the other answers here.
Some info about MELPA and MELPA "stable" -
Start by looking at this pretty-much duplicate question, from StackOverflow, including the comments for the question itself. In particular, this comment that I posted, after exchanging email with Donald Curtis (maintainer of MELPA and MELPA stable):
From his point of view [Donald Curtis's, and as I understand his communication to me], the "stable" MELPA site is in maintenance mode only. And the only reason that code like mine is not there is that no one has implemented uploading from the wiki [Emacs Wiki] for the "stable" site. Also, there is no "curating" done by anyone - no filtering to determine whether a package is stable, risky etc. The existence of two sites was requested by some package developers who wanted to distinguish dev versions of their packages from older ("stable") versions.
In sum, there is nothing that is inherently more "stable" about the content on "MELPA stable". The version numbering and feed method can be different; that's all. And if a particular package maintainer wants to distinguish "stable" from "development" versions, and wants to do that by uploading them to the two different sites, then that is the effect - for that package.
One difference between MELPA and Marmalade (and GNU ELPA) is that it is not required that code contributed to MELPA be sourced from a git repository. In particular, it can be automatically pulled from the Elisp Area of Emacs Wiki.
Does that mean, as some have said, that anyone can upload anything, and you have no way of knowing whether the code is actually by the claimed author, etc.? Yes and no. In general, yes: anyone is free to upload Elisp code to Emacs Wiki. As the top of the Elisp-Area page says:
This is the EmacsWiki elisp area, where we collect EmacsLisp files. No login required, no version control required, no ftp required, no password required. It’s as simple as the wiki itself. That also means that anybody can place malicious code in these EmacsLisp files. If in doubt, don’t use them.
However, just so you know, I am an administrator of the wiki, and my own Lisp libraries in the wiki Elisp Area are locked pages. That means that only a wiki administrator can upload them. So in this case, you can be pretty sure that libraries of mine that you download from MELPA or Emacs Wiki were uploaded by me. As with everything on the Internet, however, there is no ironclad guarantee, just as there is no guarantee with the code itself. As the GPL blurb in every GPL library says:
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
HTH. Happy hacking.
