Re: ELPA and EmacsWiki Updates

[Tom Tromey]

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

Drew> You might also consider hosting a list of "packages" or
Drew> libraries that are not Elpable, with links to where to obtain
Drew> them.
[...]
Drew> I'm guessing that you've considered this and decided against it,
Drew> but I'll still make the suggestion ;-).

:-).  But yeah, we've got the wiki and ELL for this.  Those do a
pretty good job.

Drew> That's clearly expressed, and I understand all that. My question
Drew> is why impose version numbers on _all_ "packages" just to make
Drew> them available at ELPA. IOW, the need for package versions for
Drew> some packages does not imply such a need for all packages.

Yeah, I suppose that's true.  I will think about it some more.

Drew> Again, I have nothing against adding "package-level" comments
Drew> that are specific for ELPA.

Drew> It would be preferable, of course, to do that in a form that
Drew> could be used by multiple package systems, but perhaps it's not
Drew> yet possible to standardize that.

ELPA uses a few things already defined by the Emacs Lisp reference
guide -- the Version header (though ELPA needs a specific form for the
value) and the start- and end-comments.  The start comment is used to
extract the package description.

ELPA also defines a couple new headers: Package-Version (in case
Version has the wrong format) and Package-Requires.  The latter is
used to express dependencies.

>> 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.)

Drew> Ouch! I don't want to tell you what to do or not do, but I don't
Drew> much like the idea of something (even something I initiate)
Drew> mucking with my .emacs.  Anyway, that's another story, and I'm
Drew> sure you have good reasons for doing it the way you do.

Yeah.  The goal of the auto-installer was to make it dead simple to
start using ELPA.  It is easy not to do this -- just don't run it :-).
You can still use ELPA if you install package.el by hand and edit your
.emacs, or whatever, yourself.

Basically I thought it would be fun and worthwhile to make it so
people could be running package.el in a few seconds without needing to
know anything... since after all one of my goals for ELPA is to make
it possible for folks who aren't emacs lisp wizards to run stuff --
not to mention removing the drudgery for those of us who can do it,
but would just rather not :-)

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

Drew> Ouch again!

Drew> I sure hope there is a foolproof way to uninstall - a way that
Drew> backs out all of the automatic changes that you make to a user's
Drew> environment. Been bit by this kind of "helper" tool too much to
Drew> welcome it blindly.

The load-path stuff is all done dynamically, when package-initialize
is called at startup.  To remove a package you can just "rm -rf" the
directory in ~/.emacs.d/elpa/.

Eventually I'll write package deletion support for the package menu
mode.  I've put it off.

Unloading something after Emacs has started and package.el has
initialized can't really work.  Emacs just isn't good at this kind of
thing.  There's unload-feature these days, but even that won't undo
the additions of autoloads and stuff.  So, if you want to delete
something you have to restart Emacs.  That sucks from a UI point of
view.

I keep going back and forth on the question of package activation.
Right now, if a package is installed, package.el tries to activate it
at startup.  But, we could store a preference so you can choose not to
have some activated.

One way this would be nice is if package.el was really widely used,
including to install 3rd party elisp in a distro.  Distros, in my
view, have a problem where for most users they want to enable
autoloads for all additional packages, but some power users want to
turn off certain things.  In this situation package.el would allow
deactivating the uninteresting things.

Anyway I'm not sure whether this is worth implementing.  On the minus
side it adds more complexity and UI.

Tom