DELPS - Distributed Emacs Lisp Package System by JariAalto. The DELPS is the framework, the blueprint of the design concepts. An implementation of DELPS in Git is called Epackage which follows the proven Debian packaging concepts applied to Emacs Lisp packages. The Git reference implementation is available in epackage.el. With it, you can install Emacs extensions that have been put available as Git DVCS repositories.
The reference package manager `epackage.el’ is available from the main “project hub” which points to a Git repository. See installation instructions at the end of this page.
To make an Emacs extension available in epackage format, read manual about the directory layout and used files. After that, clone Template files” mentioned below. The Template files link points to README that explains the procedure step-by-step. In Template files repository see
*.shellrc that provides shell functions which helps daily tasks with the packaging work. You must be familiar with Git, somewhat in Emacs Lisp. In Windows, you need <http://cygwin.com> and its command line Bash shell.
Emacs has been around for decades now. Many new version have come and gone. And yet there are wealth of useful extensions available e.g. at <http://emacswiki.org> that add new features not yet available in standard Emacs. The typical procedure to add a new extension to Emacs has been:
That’s quite a bit of work for each extension; reaching thousands out there. Many Linux distributions offer package managers to download and install programs. E.g. Debian has command apt-get/aptitude Redhat uses rpm and Suse uses yast. See also YUM. So why not make one for Emacs as well.
The epackages are in the form of distributed Git version control repositories. The traditional packaging methods, like ELPA, rely on archives like
*.tar.gz. In contrast, the DVCS approach offers interesting features over the traditional archive distribution approach:
In the picture above, the user downloads Sources List yellow pages that contains information about available packages. At upper right: when a prospective developer wants to make an epackage available for others, he first forks the current Sources List (yellow pages), adds new information to it and sends a pull request inside Github.com to ask to merge changes back to the master. The epackage maintainer keeps an eye on new upstream releases and provides new epackages by updating his publicly available Git repository. To the lower right: it is possible that upstream and the epackage maintainer is the same person. This is the ideal situation.
Each Emacs extension is wrapped into epackage format which basically follows the Debian packaging style where a separate control directory named
epackage/ is used for all the packaging details: activation, autoloads and installation etc. In addition, each epackage is imported in and deployed using Git Distributed Version Control System (DVCS). A specific Sources List file lists the available Git repositories where user can download packages. Once an epackage has been downloaded, subsequent downloads are very efficient because only deltas are transferred.
The reference implementation is available at Github. Mirror at Savannah:
# Location where you keep your Emacs extensions mkdir -p $HOME/emacs.d/packages cd $HOME/emacs.d/packages
# Or use mirror: git://git.savannah.nongnu.org/emacs-epackage.git git clone git://github.com/jaalto/project--emacs-epackage.git epackage
cd epackage git checkout --track -b devel origin/devel
# to get new updates from time to time git pull
Add following to your `~/.emacs’ startup InitFile