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 ...
First of all, ELPA is the name of a specification, the Emacs Lisp Package Archive. There's three widely known implementations of that specification, GNU ELPA, Marmalade and MELPA.
GNU ELPA is the official GNU Emacs archive, enabled out of the box for sufficiently new Emacs installations. It is comparatively small, contributing to it requires copyright ...
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:
GNU ELPA requires all code to be GPL'd and copyright assigned to the FSF. ELPA code is essentially "owned" by the core Emacs team, so there's much less of it than ...
Use the option package-archive-priorities which was made for this very purpose. To prefer MELPA Stable over MELPA, add the following to your init file:
'(("GNU ELPA" . "https://elpa.gnu.org/packages/")
("MELPA Stable" . "https://stable.melpa.org/packages/")
("MELPA" . "https://melpa.org/packages/"))
There are several package repositories available.
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 ...
The problem you're referring to is probably that when you upgrade a package from within an Emacs session where that package is already in use, the old version of the package will sometimes interfere during compilation of the new version, leading to miscompiled files.
There is a tentative fix for that in Emacs-25, but AFAIK the problem is still present in 24....
I set up a local package archive (Emacs 24.5) using package.el by first creating two directories, pkgs and local. (The names don't matter.) The files comprising your packages go in pkgs, and local will end up holding your archive. If you want to make an archive available to others, you can expose local using a web server, but the process is the same as ...
set package-check-signature to nil, e.g. M-: (setq package-check-signature nil) RET
download the package gnu-elpa-keyring-update and run the function with the same name, e.g. M-x package-install RET gnu-elpa-keyring-update RET.
reset package-check-signature to the default value 'allow-unsigned`
This worked for me.
FWIW - I had this issue with the signature org-20140407.tar.sig. Like Sigma's package-check-signature is/was allow-unsigned.
I changed the package-check-signature value to nil and the problem was resolved.
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):
You can't install a previous version of a package in our current infrastructure. Even though Emacs’ built-in package manager now supports multiple versions of a package in recent releases, no popular package archive (i.e. MELPA Stable and Marmalade) actually keeps a backlog of previous releases.
Emacs didn't support this for a long time, and now that it ...
If you try to install the package gnu-elpa-keyring-update (which seems to have the purpose of updating the keys used by the package manager), you will see in its description that you can do:
gpg --homedir ~/.emacs.d/elpa/gnupg --receive-keys 066DAFCB81E42C40
on the commandline to get new keys manually. To make sure you are asking for the correct key (...
With the notable exception of ProofGeneral, I'm not aware of any major Emacs package that's not available in some ELPA archive. Specifically, ESS is on MELPA since three years. And PG is a story on its own, and definitely not representative for the whole Emacs ecosystem.
ELPA surely has its flaws, but for the vast majority of packages it works just fine,...
You want to change the variable package-user-dir:
(setq package-user-dir "~/.emacs.d/packages")
Change this setting before calling (package-initialize) or anything involving loading or installing packages, but after (require 'package).
How I found this:
I use Helm, which makes it easy to search through Emacs's functions and variables. I called describe-...
When you update your packages through the M-x list-packages interface, after the successful installation of the package, you'll get asked if you want to remove the old package. Don't delete them so they stay in place and you could then later remove the newer package through this interface.
My current package list shows 4 versions of magit installed in my ~/....
It is true that MELPA no longer pulls libraries from EmacsWiki.
Please obtain Dired+ and other libraries by me from EmacsWiki: dired+.el.
All of my pages on EmacsWiki are locked (they require a site administrator to unlock them). There has never been an actual security problem reported, AFAIK.
Yes, it is true that a locked web page does not present the ...
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 ...
Well you've answered your own question: package.el is the standard way to install packages, because it's built into Emacs 24.
Everything else is non-standard (and probably somewhat subjective. I manage most third-party libraries via el-get, personally).
The basic way to use packages^(1) is pretty simple:
Add to your init file:
(require 'package) ;; You might already have this line
'("melpa" . "https://melpa.org/packages/"))
(when (< emacs-major-version 24)
;; For important compatibility libraries like cl-lib
(add-to-list 'package-archives '...
Melpa's source is available, so you could just clone and run that on a server configured to be accessible from only inside your office (and not the whole internet). Your developers would have to be able to access the server, and would have to add the archive to package-archives the same way one does Melpa, Marmalade, or others. The packages would show up in ...
As pointed out by Nsukami, package.el does support system-wide packages. But as your subsequent question points out, it does not provide any special help to install packages in a system-wide manner.
One way you can do that is by using something like:
(setq package-user-dir "/usr/share/emacs/site-lisp/elpa")
in your root account's ~/.emacs. This will ...
The "nuclear option", as it were, would be to ditch package.el entirely and instead use the package manager that I wrote, straight.el. The advantage would be that straight.el installs packages by cloning their Git repositories, thereby making it trivial to use whichever version you would like. Also, straight.el provides functionality for dealing with ...
The server configuration on marmalade.org is broken: It does not serve the intermediate certificate it is using. This has been pointed out in half a dozen of issues now at https://github.com/nicferrier/elmarmalade -- I can discern no action.
So one can say that marmalade is defunct.
Unfortunately, I also don't know yet how to make the Emacs package ...
The correct solution (IMO) is to use a package manager which has explicit support for this use case. This would be straight.el, which I wrote for this purpose.
You can read verbose documentation, including comparisons to other package managers, in the README, so I'll stick to how you can use straight.el to solve your specific problem.
Place your repository ...
Is this normal?
Yes, MELPA recently updated its policy and no longer includes packages hosted on EmacsWiki, quoting security reasons: https://github.com/melpa/melpa/pull/5008. See also Drew's answer.
For now you will have to install it either from its upstream EmacsWiki source at https://www.emacswiki.org/emacs/dired%2b.el or from its (potentially outdated)...
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 ...
'(("melpa" . "https://melpa.org/packages/")
("gnu" . "https://elpa.gnu.org/packages/")
("org" . "http://orgmode.org/elpa/")))
to your emacs init file. Adding the org repo will put the latest version of org-mode in list-packages, where you can update it just like any ...
The version of cl-lib in GNU Elpa is a backport of the cl-lib from Emacs 24.3 intended for Emacs <=24.2. (Or put differently it is a forward compatibility wrapper around cl as it comes with <=24.2). If you are using Emacs 24.3 then you don't need it and when you use package.el from that Emacs version it will never install any version of cl-lib because ...