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.
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.
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.
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.
thanks, Phil Hagelberg http://technomancy.us
* 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.
Helmut