[slime-devel] Packaging for ELPA

Helmut Eller heller at common-lisp.net
Mon Oct 19 18:30:50 UTC 2009

* Phil Hagelberg [2009-10-18 07:13+0200] writes:

> Recently on the emacs-devel mailing list there has been a discussion
> about including a package manager in Emacs for the next release. This
> should greatly ease the installation of elisp packages that are not
> included in Emacs.

We'll see.  I'd rather use apt, rpm or whatever package manager the
system uses for this purpose.

> I have been using SLIME for Clojure work for a while now and am
> maintaining the swank-clojure adapter for it. I'm planning to submit the
> elisp portion to ELPA, which is the package manager that is slated for
> inclusion to Emacs. This means I'll also need to submit SLIME, since
> it's a dependency.

Tom Tromey once asked if he should include Slime but he was rather
discouraged by the fact that we don't make releases.

There are also issues with the license as the FSF will probably only
include packages for which they have copyright assignments and for Slime
dozens of people would need to do the paperwork.

> I've done the initial work to convert slime.el and slime-repl.el into
>packages that can be used with ELPA. The changes have been pushed to my
>github repository at http://github.com/technomancy/slime under the
>"elpa" branch.
> If I could get a cursory overview from one of the Slime developers it
> would be great. This should make it easier for all users of Slime to get
> it installed, especially once the package manager gets merged to Emacs.
> If the changes are good, I can also push them back upstream. Right now
> there is one change that is inappropriate for mainline Slime--I replaced
> the body of slime-changelog-date to use the package manager version
> instead of parsing the ChangeLog file from disk, but if you would like
> me to push my changes upstream I can make it so it uses the ChangeLog if
> it's present, falling back to the package manager otherwise. The other
> changes are very minor; mostly just changing comment headers and adding
> autoload directives.

I/we don't want/can't support different versions and the canonical
version is and will always be the current CVS version.  So yes, the
ChangeLog file should take precedence.  

Some of those ###autoload directives are at strange places, e.g. before
progn or autoload.  That doesn't make sense to me.

> Is this a good time for me to do this? I know Slime doesn't do formal
> releases, but if there are some changes happening in the codebase right
> now that would mean it would be better to wait, please let me know.

I'm not aware of any expected unusual changes.


More information about the slime-devel mailing list