The aim of this wikipage is to design a packaging system for Emacs Lisp software.
For off-the-wiki discussion please contact JoseEMarchesi
Regarding elisp programs distribution, consider the following issues:
There are dozens of elisp packages lurking on the network, hosted on dozens of websites. It is usually tedious to search for some specific package or (even worse) for some package that implement some desired functionality. Elisp software repositories (like the ElispArea) minimizes the need for deep internet search.
So there is a real need for elisp software repositories.
Ok… installing elisp software is in theory a trivial task. Just copy a file such as `foo.el’ into some directory, update your
‘auto-path’ if necessary and then
‘require’ it. But in practice some troubles arise:
So there is a real need for common installation procedures.
Attending to package’s file hierarchy:
Attending to package’s contents:
Binary packages… makes sense? Here goes some reasons for not considering “binary packages”:
We still need to list the arguments for not taking the existing packaging thing from XEmacs. Too complicated? Many users seem to run into errors when installing it for the first time, eg. when EFS is not installed. – AlexSchroeder
bohoan (from the #emacs channel) just directed my attention to a very interesting elisp package called install.el It is written by StefanMonnier. I am reading the code right now. From what i see, install.el is very likely to be a great basis to implement rational elisp packaging. I am very excited ☺ – JoseEMarchesi
What about a new file format. .elp (Emacs Lisp Package) that when dragged and dropped (w32) or opened (all), emacs will present the contents of the package and offer to install and configure it? – MaDa
The package-specific file type is the classical approach. Another (perhaps better) approach would be to insert the package metadata (and configuration/installation launcher) into the `Local variables:’ section:
;;; Local variables: ;;; elp-package-type: 'flat-one-file ;;; elp-package-emacs-flavors: '((gnuemacs 21.3) (xemacs 21.2)) ;;; elp-package-requires: '(fooplibrary barlibrary) ;;; eval: elp-launch-installation ;;; End:
In that way elisp libraries composed by only one file ‘foo.el’ wont become overloaded by extra packaging metadata on extra files. Packages composed by several files could include such local variables on, say, `install-package.el’ or, alternatively, insert it into the main source file (such as ‘erc.el’). – JoseEMarchesi
I’ve been working on package.el, a simple Emacs packaging system. It handles versions, installation, activation, and has a buffer-menu-like interface to package management (including downloading things from the package archive).
It is still pretty early in development, but you can already use it to install a few fun packages, like the bubbles game.
Read the pointed-to thread for more information. Current work includes changing how activation is handled, so that startup is faster.
Ultimately what I would like to do here is have this incorporated directly into Emacs, and also set up a package archive (I’m calling it “ELPA”) as a project on savannah. Then, hopefully, developers would migrate their lisp code from ELL, gnu-emacs-sources, and the wiki to ELPA.
Currently ELPA is hosted on my site. There’s an auto-installer there; it only takes a minute (and no editing) to get set up. Please take a look, and please submit your packages for inclusion in ELPA. – TomTromey
Note: the program ‘inversion.el’ which is a part of CEDET does version checking via ‘require statements, loaded data files, and the like. It could provide a simple baseline for version checking. - EricLudlam
I wrote a new packaging system based on lessons learned in how Debian packages software. These concepts were applied to packaging Emacs extensions.
In this system packages are available in a form of distributed git version control repositories. The traditional packaging methods (like ELPA) have previously relied on archives like *.tar.gz to hold the code. In contrast the DVCS approach offers important features over monolithic archive approach:
Each Emacs extension is “pacakged” like this: (1) upstream code is imported into a Git repository, (2) the epackage system is installed on top of upstream code in a separate
‘epacakage/’ directory, (3) the Git repository is made available online and (3) information about the availability of new package is recorded and to a separate seources list yellow pages; which is available on-line.
The epackaging work can be done by anyone who wants to set up a Git repository. The location of repositories doe snot matter. The whole system is decentralized as far as packages are ocncerned. The packaging work doesn’t necesarily have to be done by the original Emacs extension author (upstream) who may not be familiar with the `git(1)’ but someone who has interest in the package in general.
JemPkg is my approach to Emacs local installation management. It is more a “home manager” than a packaging system, but i am introducing some packaging capabilities to it: currently, it support one-file packages using file local variables (no need to package these one-files hacks into tar.gz).
Among other things, it provides a major mode to manage local configuration for installed packages. – JoseEMarchesi
Pases is my attempt at a packaging system for Emacs. Documentation is a little sparse right now. Basically a “package” is a .tar.gz file with the extension .pases. It should be intsallable by Emacs alone. Doesn’t do much in the way of version management, dependencies, etc. right now, but does handle a) byte-compiling, b) load-path installation, c) info load path installation. Do let me know if you have any comments or suggestions! – ErikHetzner