Re: ELPA and EmacsWiki Updates

[Tom Tromey]

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

Drew> If your concern is also about your site becoming infected, then
Drew> perhaps this could be done on a different site - perhaps the
Drew> wiki itself.

My concern is that, if an automated approach becomes popular, then it
is more worthwhile for people to try to slip in trojans.

Of course there are no guarantees.  But with ELPA I'm usually in touch
with the authors, or I'm uploading an established package.  With the
Wiki there is little oversight.

Even better would be some Debian-like web-of-trust thing, and package
signing.  But, that could come later I suppose, if needed.

Drew> The ELPA version is likely to be stale, due to my laziness.

Then that's another reason that ELPA is not a good match for your
purposes.  I don't think it is too valuable to users to host stale
packages.

Drew> But why the constraint that a package have an overall version number?

Here is a (semi-) real example.  ELPA includes EMMS.  But, I've heard
that someday EMMS will be included in Emacs.  And, I suppose that EMMS
will continue to be developed outside Emacs as well -- this is common
for larger packages (gnus, erc, etc), especially because Emacs has a
very slow release cycle.

Suppose I install EMMS 3.0 now, then sometime later upgrade to Emacs
23 which (let's suppose) includes EMMS 3.1.  How does package.el know
which EMMS to use?

This is the scenario I wanted to solve -- one that has bit me numerous
times over the course of my Emacs life.  Version numbers are a simple,
conventional way to solve it.

To continue the scenario, if EMMS 3.2 comes out, I can upload it to
ELPA and folks can use it; and when they upgrade to Emacs 24 they
won't have to do anything special.

This isn't the only thing ELPA is good for, but it was one of the use
cases I designed for.

Drew> Why not separate this physical packaging from the logical
Drew> packaging that is simply declaring the set of needed files?

I thought about things like this.  But, in the end I decided to try
KISS as much as possible.  And it turns out that most packages fit
nicely into this approach.

Drew> It would be great if an author could simply register a package
Drew> description with your site, and have the site automatically
Drew> periodically retrieve the requisite files from a specified
Drew> source (which in my case would be Emacs Wiki).

This opens the trojan door again.

Also, IME it is rare for packages to be upload-ready.  They typically
don't follow the comment guidelines.  Packages with dependencies on
other packages need ELPA-specific comments as well.

Your ideas are interesting though.  I'm just not sure they would work
that well in practice.  E.g., I've looked through ELL numerous times.
It is, unfortunately, full of broken links.  That is something that is
inevitable with a multi-site approach.  Instead I was trying for
something like "Ohio State Elisp Archive meets CPAN-ish trivial
install".

Drew> Maybe I'm missing the boat here. The package system doesn't
Drew> actually install packages for the user, does it? It just makes
Drew> them available for download, right? And it controls (checks)
Drew> dependencies and maybe other potential consistency gotchas,
Drew> right?

Nope, it does download, dependency resolution (both at activation time
and download time), and install.  And deletion, too, whenever I get
around to it.

FWIW you can try out ELPA in just a couple minutes.  There's an
auto-installer on the web page.  Run that, then:

* M-x package-list-packages
* "r" (re-reads the package list from ELPA)
* "i" to mark for install, "x" to execute the installs

I suggest 'bubbles' as a starter package.  After it is installed,
M-x bubbles.

Drew> I can see why ELPA allows package versions, for example, but why
Drew> would it require them for all packages it handles?

Simplicity.  Honestly I didn't consider that there would be a package
without a version.  Versioning is just, well, conventional and normal
:).

Drew> I figured it was only downloading. How does ELPA help a user install and
Drew> compile? Do you provide make files etc. that one can use on various
Drew> platforms, or how does it work?

ELPA takes a very simple approach.  It downloads the package and
installs it in ~/.emacs.d/elpa/, then byte-compiles the .el files.  It
also extracts autoloads.  If those things don't work, I simply don't
upload the package.

The auto-installer adds a line to your .emacs.  When Emacs starts,
package.el will do a dependency check and activate whatever packages
it can.  (So, e.g., you can change Emacs versions and things mostly
still work.)

Activation means modifying load-path and evaluating the autoloads.  If
the package contains a 'dir' file, package.el also modifies the info
path.

>> * Automatically handle package dependencies

Drew> Dependencies between packages or just among the files of a package?

Between packages.  E.g., lisppaste or weblogger require xml-rpc.  If
you install one of the former, the latter will be installed.  Likewise
for activation.

One other big goal for ELPA was to take the pain out of installing
Emacs Lisp packages -- to focus on the user experience.  We certainly
could write something "dumb" (not meaning that in a bad way) that
simply downloads a .el and drops it somewhere.  In my view this only
solves part of the problem... dependencies matter too.  So do some
things not easily enforceable in a tool: does the package have
autoload comments in place?  Does it respect Emacs namespace rules?
Key-binding rules?  Etc.  I do try to review packages for things like
this before uploading (e.g., that is why quilt.el isn't there).

So, part of the mission here is raising the standards for Emacs
add-ons.

Drew> Is it also OK if there is no notion of upgrading, for some package?

Since version numbers are assumed, all upgrading means is, install a
newer version.


Anyway, I hope I've answered your questions.  I didn't answer them all
since I thought some of the answers would be redundant given other
answers.  If I missed something important I'm happy to talk and talk
about ELPA :-)

Tom