in which, were a title to be summarized from the content, it would be altogether too similar to many of the titles used for past articles, possibly to the point of indistinguishability

Anyone who follows my exploits will have noticed I'm a tireless proponent of ELPA, the Emacs Lisp Package Archive. As a maintainer of several Elisp libraries, ELPA makes my life easier by helping me sidestep the boring problems of distribution and installation. You may not know that package.el, the software behind ELPA, has been submitted for inclusion in the next version of Emacs. I've taken up the task of getting it ready.

Including something like package.el into Emacs is a big job, and it's something that can only happen gradually. Emacs comes with a number of applications such as Org Mode and Gnus that are developed externally to Emacs and merged periodically into the main Emacs source tree. If they were to be redone as packages they could still be distributed with Emacs builds but kept out of the source tree. They could also be upgraded and installed/removed independently of Emacs' historically long release cycles.

If you've submitted packages to ELPA before, you know it's a process that could use some streamlining. Currently it's all done by email, and packages must be manually uploaded by a single maintainer before they appear to users. This has long been the biggest shortcoming of ELPA. I've written some additions (package-maint.el) that allow you to automate the maintenance of a package source. Basically you provide it with a list of git URLs, and it will check out each tagged version and create a package from it. Of course, that wouldn't be useful without giving clients the ability to get packages from multiple sources at once, which I also added to package.el.

If you maintain any Emacs packages of your own, please try out my changes to package.el. If you use any of my packages, try upgrading and adding my package source to your list.

(add-to-list 'package-archives
             '("technomancy" . "http://repo.technomancy.us/emacs/") t)

That way you'll get access to my updates as soon as they're tagged rather than waiting for them to be manually uploaded, though currently the latest versions of all my packages are in ELPA. Next steps are closer integration with Emacs in order to have packages installable on a system-wide level as well as a per-user level, prerelease version number support, and extraction of some built-in Emacs libraries as packages. Suggestions, bug reports, and patches welcome!

« 2010-01-31T18:10:28Z »

Larry Diehl – 2010-01-31T20:11:33Z: Awesome job man. I have to admit to deciding that ELPA was too much of a bother after figuring out it required email submission and manual review. Also, the instructions for packages consisting of more than one file looked too bothersome.

Given that the new rubyforge/gemcutter project is open source (and other projects like javagems.org taking advantage of that), it would be hella cool to see a similar site for elpa.
Alex – 2010-02-01T04:01:41Z: Out of interest how does package.el deal with version dependencies. For example if you want to track the more recent org-mode than what is packaged with emacs itself? What about the danger of tracking a package that adds dependencies on core emacs features only available in more recent snapshots?
dim – 2010-02-01T08:06:14Z: I'd like to have something like debian dpkg --get-selections and --set-selections, a simple way to store the current package list (per archives, maybe).

Then I'd only store that in my .emacs.d, and when installing emacs on a new environment I could package-set-selection or something, then package-dselect-upgrade or a better named function would apply it by installing what I need.

It could even be a routine thing to pull from the emacs.d git then resync the package installations from the saved list.

Regards,
Scott – 2010-02-01T12:16:26Z: Do you have a specific inspiration for this style of title? It sounds a lot like Dickens in The Pickwick Papers.
Ed Singleton – 2010-02-01T16:36:43Z: I had a similar idea myself, and started having a bash at implementing it: http://github.com/Singletoned/package.el (largely inspired by your ESK)

Unfortunately I was somewhat hampered by not really knowing much lisp, and only occasionally putting much effort into it. I certainly learned a lot from trying it, and I'm glad that someone better is giving it a serious go.

My main motivation for it was the build up of packages in my ~/.emacs.d/elpa-to-submit folder. Are you intending that anyone can submit packages (through pull requests I assumed), or that only the package author can?
piyo – 2010-02-02T14:39:14Z: Great stuff! Were there some lessons learned from the packaging system in Xemacs?
Phil – 2010-02-04T10:19:15Z: @Alex: right now version dependencies are just done on a "must have at least" level. If a package depends on a package that depends on a newer version of Emacs than you've got installed, package.el should refuse to install it. But the second package must indicate that it depends on a recent version of Emacs.

@dim: That would be super! The Starter Kit kind of does this, but it could be done much better by integrating with package.el. Why don't you give it a shot? It shouldn't be too hard.

@scott: My inspiration for the titles is Umberto Eco's excellent "The Name of the Rose". This post in particular was inspired by Chapter Seven: "In which, if it were to summarize the prodigious revelations of which it speaks, the title would have to be as long as the chapter itself, contrary to usage." It's a brilliant novel; I can't recommend it enough.

@Ed: Anyone may submit packages to ELPA, though it's only polite to notify the author first. But my hope is that there will be alternative package sources so not everything must go in ELPA.

@piyo: I must confess complete ignorance to XEmacs' packaging system, though I believe Tom (the original package.el author) read up on it a bit.