SiteMap Search ElispArea HowTo Glossary RecentChanges News Problems Suggestions

RationalElispPackaging

The aim of this wikipage is to design a packaging system for Emacs Lisp software.

Please contribute!

For off-the-wiki discussion please contact JoseEMarchesi

Motivation

Regarding elisp programs distribution, consider the following issues:

Software localization

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.

Software installation

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.

Requisites

Anatomy of an elisp package

Attending to package’s file hierarchy:

Simple packages
composed by one elisp source file.
Flat packages
composed by several files on one directory.
Structured packages
composed by a directory hierarchy.

Attending to package’s contents:

Pure packages
composed only by elisp source files.
Non-pure packages
composed by both elisp source files and data (documentation, images, etc).

Binary packages… makes sense? Here goes some reasons for not considering “binary packages”:

What is the right approach?

I very much agree with AlexSchroeder that a good starting point would be to write a library containing useful functionalities for installing elisp programs. - JoseEMarchesi

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

Ideas

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

package.el - Emacs Lisp Package Archive (ELPA)

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

Epackage - Distributed Emacs Lisp Package System (DELPS)

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[1] git[2] version control repositories. The traditional packaging methods (like ELPA[2]) 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.

For more information, see wiki pages DELPS and Epackage

JariAalto

jempkg.el

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

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

el-get

See el-get (author is DimitriFontaine)