EmacsWiki: DELPS (original) (raw)

Description

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.

For Regular Users

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.

For Package Developers

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.

History

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.

Concepts

The epackages are in the form of distributed[1] Git[2] 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:

EpackagePictureDelpsDiagram

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[3] 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.

Download and Install

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:

(load "~/.emacs.d/epackage/00conf/epackage-loader" 'noerr)


(autoload 'epackage-manager "epackage" "" t)

The epackage manager can also be called from command line UI:

Start command line UI

cd epackage make ui

# Or if you want to make a shell alias or function, the command needed is
emacs --batch --quick --load ~/.emacs.d/packages/epackage/epackage.el --funcall epackage-batch-ui-menu

ELPA and Epackages - What's the difference?

The big question probably is: “What’s different to ELPA? Where do we need Epackages when Emacs 24 and later already comes with ELPA built-in?” Lots. The DVCS approach is completely different and changes the scene dramatically. The ELPA is based on old design (centralized, need for server and administration). In contrast, the DVCS is the future in both the concept (distributed) and the use of tools (version control).

For the user

For the developer

Downsides

How to make an epackage

How does it all work? Let’s say, we’ve found example.el which seem quite useful. Note that in this example all the proper comment headers, licensing information, provide calls etc. have been omitted for brevity:

(defun example-mode (&optional mode)
  (interactive "P")
  (message "example-mode in use"))

To prepare the Emacs Lisp extension into epackage format, we drop into shell. We have already two development directories cloned which provide e.g. shell utilities. See heading For Package Developers for development files. The steps are:

# This example is for the Bash shell
# Prepare and use utilities from 2 cloned Git repositories

export EPACKAGE_ROOT=~/git/project--emacs-epackage
. ~/git/project--emacs-epackage-template/epackage.shellrc

# See short help
Ehelp

Provides following user commands. The rest are just internal
helpers. Use --help for each command for more detailed information.

    Egit [URL]                 Import current src, from URL, or
                   emacswiki:FILE.el

    Ever [file.el ...]         Display version and deps information
                   from all, or given files

    Edir <PACKAGE NAME> FILE   From FILE determine and create epackage/
                   template files

    Edef [dir]                 Update loaddefs in epackage/ directory
    Elint file.el ...          Lint files to find QA violations
    Ecomp file.el ...          Byte compile Emacs Lisp files (QA check)
    Eclone GITURL              Clone an existing epackage and set up
                   branches (dev only)

# Start packaging
cd ~/my/elisp/package/example/

# Inject extension into Git branch "upstream"
Egit

# Tag this realease
git tag upstream/YYYY-MM-DD

# Change to standard branch which will hold the "epacakage"
git branch master upstream

# Install templates and epackage/ directory structure
Edir example-mode

# Fill in package details
$EDITOR epackage/info

That was it in a nutshell. What’s left to do is to check the generated files, adjust or delete them as needed. E.g. we don’t need for this simple extension files like *-compile, *-examples, *-uninstall and we can simply delete them. We have to fill in the important info file that defines details of the package. After all changes, we commit to Git, make this new epackage available (push to Github) and announce its availability in epackage yellow pages; among other packages.

The directory structure is as follows. For a complete example with all the details, see heading For Package Developers.

example.el
|
+- epackage/
   example-epackage-0loaddefs.el
   example-epackage-autoloads.el
   example-epackage-compile.el
   example-epackage-examples.el
   example-epackage-install.el
   example-epackage-uninstall.el
   info

Contact

Please send comments, suggestion, ideas, bug reports to me directly or to the bug tracker. Please do not add questions to this page as this page is not monitored. Thanks --Jari

Pictures and History

EpackagePictureUiCommandLine

CategoryPackaging epackage bare bones Template files