Re: ELPA and EmacsWiki Updates

[Tom Tromey]

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:

>> FWIW, the reason that Icicles is not in ELPA is that the Icicles
>> author did not want it there.

Drew> Hmm. That's not quite right, Tom. What I said at the time was
Drew> that it seemed (then) that some package system (possibly ELPA)
Drew> would soon be added to Emacs, and I was intending to wait to see
Drew> what Icicles changes might be needed to adapt it for use with
Drew> the (future) standard package system.

Ok.  I must have misremembered, thanks for clearing that up.

Drew> However, it's also true that I said that (1) I appreciate the
Drew> simplicity of uploading to Emacs Wiki

Yeah.  That is simpler, for sure.  I considered having ELPA download
straight from the wiki, but I was not comfortable with the
uncontrolled aspect of it.  My concern was that if ELPA became
commonplace, someone would upload a trojan.

Drew> I'm not too clear on what I would need to do - feel free to
Drew> contact me about it. Especially if it's just a one-time change,
Drew> and not too difficult, it's likely that I will do it.

I documented what to do for single-file packages on the web site.  For
a multi-file package, you must:

* Put all the files into a .tar which has the package name and
  version.  The files must be in a directory of the same name.  E.g.,
  the package "emms-3.0.tar" the files must all appear beneath the
  top-level directory "emms-3.0/"

* Make a -pkg.el file in the package.  This holds the call to
  define-package.  E.g., "emms-3.0/emms-pkg.el".  The define-package
  call sets the version number, description, dependencies, etc.

* If you have a texinfo manual, make a .info file and a dir file and
  put those in the package directory in the tar.

In other packages I've ELPA-ized, I made a 'make elpa' Makefile target
to run info, run install-info, set the version number in the -pkg
file, and make the tar.

Drew> Is there a way for ELPA to get stuff automatically from Emacs
Drew> Wiki - that is, stuff that has been made Elpable? That would be
Drew> a big help.

There isn't.  For a multi-file package it would have to be pretty
complicated.

Drew> It would be great if library authors could simply upload to one
Drew> site and have the others feed off of that. (Via RSS? I don't
Drew> know anything about RSS, so don't laugh if it's irrelevant
Drew> here.) Emacs Wiki already mirrors the Emacs-Lisp List, but it
Drew> would, IMO, be much better the other way around: it would be
Drew> good if other sites that are more like simple repositories fed
Drew> off of the code posted to the wiki.

Yeah.  For the Wiki the security issue concerns me quite a bit, but
maybe this could be fixed somehow.  My plan for ELPA was to move to a
hosting site that would more easily allow multiple maintainers, but I
haven't done that yet.

Drew> The wiki has no notion of packages, however, so it would be
Drew> helpful if a package system such as ELPA could feed off of the
Drew> wiki somehow.

My experience based on looking at a *lot* of Emacs packages is that
the solution will never be as convenient for authors as "dump it on
the wiki".  A nicely (IMO) functioning system will always require
meta-data; the typical Emacs Lisp program handles this by a comment
and dropping the problem on the user.

Drew> See my comments above. In my case, I don't make package
Drew> "releases"
[...]
Drew> I'm not against a package system, depending on what that means,
Drew> but it would be ideal, I think, if packages were more or less
Drew> virtual, updated automatically whenever a member file is updated
Drew> on the wiki.

I see.  ELPA is not a good fit for what you want then.  Most
non-trivial Emacs packages are developed along more traditional lines,
with releases and (non-wiki) version control, etc.

ELPA was designed to solve a few problems that I encounter:

* Download, install, and compile a package
* Automatically handle package dependencies
* Handle upgrading a package
* Handle the case where an external package is incorporated into Emacs
  core but also has ongoing external development.  This is the
  requirement behind much of the versioning support -- the idea is to
  always choose the newer package regardless of where it appears.

Tom