Summary: (For the developer): Last bullet: mention no more packaging process overhead. Chnage all links to WIKI format (flagged as spam on page exit).
< * Project hub (never moves, bookmark this; you can subscribe project announcement):
< * List of [https://github.com/jaalto/project--emacs-epackage-sources-list/blob/master/epackage.lst available packages for install]
> * [http://freecode.com/projects/emacs-epackage Project hub] at Freecode.
> Never moves, bookmark this; you can subscribe project announcement
> * List of [http://github.com/jaalto/project--emacs-epackage-sources-list/blob/master/epackage.lst available packages for install]
< * Manual: http://www.nongnu.org/emacs-epackage/manual
< * Template files:
< * Sources List (yellow pages):
> * [http://www.nongnu.org/emacs-epackage/manual Manual]
> * [https://github.com/jaalto/project--emacs-epackage-template Template files]
> * [https://github.com/jaalto/project--emacs-epackage-sources-list Sources List (yellow pages)]
< gone. And yet there are wealth of useful extensions available e.g. et
> gone. And yet there are wealth of useful extensions available e.g. at
< http://dir.gmane.org/gmane.emacs.sources or
> [http://dir.gmane.org/gmane.emacs.sources gmane.emacs.sources] or
> [http://www.emacswiki.org www.emacswiki.org]
< command *apt-get*/*aptitude* , Redhat uses *rpm* , Suse
< uses *yast* . So why not make one for Emacs as well.
< *  http://en.wikipedia.org/wiki/Advanced_Packaging_Tool
< *  http://en.wikipedia.org/wiki/RPM_Package_Manager
< *  http://en.wikipedia.org/wiki/YaST See also
> command [http://en.wikipedia.org/wiki/Advanced_Packaging_Tool apt-get/aptitude]
> Redhat uses [http://en.wikipedia.org/wiki/RPM_Package_Manager rpm]
> and Suse uses [http://en.wikipedia.org/wiki/RPM_Package_Manager yast]. See also
> [http://en.wikipedia.org/wiki/RPM_Package_Manager YUM].
> So why not make one for Emacs as well.
< with the upstream e.g. through http://github.com
> with the upstream e.g. through [http://github.com Github]
< *  DVCS = Distributed Version Control System
< *  http://git-scm.org
< *  http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-control
> *  [http://en.wikipedia.org/wiki/Distributed_revision_control DVCS]
> = Distributed Version Control System
> *  [http://git-scm.org Git homepage]
> *  [http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-control Debian packaging manual, Chapter 6. Best Packaging Practices]
< * Low maintenance. Just concentrate on doing what you do best:
< improving your Emacs Lisp utility. No distribution hassles.
> * Low maintenance. No more release prcess overhead which includes
> making .tar.gz, ensuring README and NEWS to be
> up to date, packaging wrong release etc.
> Just concentrate on doing what you do best:
> improving your Emacs Lisp utility. No distribution hassles (ssh or
> logging to a remote site, web page etc.)
< * Bug Tracker
> * [https://github.com/jaalto/project--emacs-epackage/issues Bug Tracker]
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 “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 functions which help in doing 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:
‘~/.emacs’to arrange loading the extension to one’s liking.
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:
;; One big file to boot all installed epackages ;; Automatically generated. Do not edit. (load "~/.emacs.d/epackage/00conf/epackage-loader" 'noerr)
;; M-x epackage-manager to start UI (autoload 'epackage-manager "epackage" "" t)
The epackage manager can also be called from command line UI:
emacs --batch --quick --load ~/.emacs.d/packages/epackage/epackage.el --funcall epackage-batch-ui-menu
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
‘load-path’support added. You still have to manually configure each and every ELPA package by adding the necessary lines to ~/.emacs InitFile.
For the developer
Please send comments, suggestion, ideas, bug reports to me directly or to the bug tracker. Please do not send questions to this page as this page is not monitored. Thanks --Jari
‘epackage-manager’available, just the “bare bones”.
CategoryPackaging epackage bare bones Template files