Re: package.el

[Tom Tromey <tromey@redhat.com>]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> I just had a look at package.el. A few comments:

Thanks for your time and your feedback.

If emacs-devel folks don't like this traffic here we can move it
elsewhere.  `elpa@tromey.com' is my package.el address.

>> If you don't know what "eval" means, it means that you should copy
>> this into your *scratch* buffer, move your cursor just after the
>> final closing paren, and type C-j.

David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j might
David> not work. M-x eval-region would!

I wasn't aware of this.  Is this a common situation?  Those
instructions are intended for people who know very little about Emacs;
are they likely to have changed the mode for *scratch*?

David> From your installer file:
David> (expand-file-name "~/.emacs.d/elpa")
David> please don't assume that this directory is something where you can
David> (or the user wants to) install things.

David> There should be a customization variable for this. This applies
David> to package.el itself as well, where you have a defvar, not a
David> defcustom, for package-user-dir.

Yes, I agree.  I don't know much about custom (my last emacs lisp
hacking experience predates the existence of custom -- sad but true).
But I will learn and I'll make the appropriate fix.

However, for the installer, I think this is an ok choice.  I don't see
how we would support customizing the package install directory before
actually installing package.el.  And, I suspect users who know about
and use features like this probably won't have much trouble hand
installing package.el.

What do you think about this?

David> In package.el, I'm not sure what's going on with `package-activated- 
David> list', but you seem to make assumptions about which packages are
David> installed by default.

Yes.  package.el knows a bit about which packages are shipped as part
of Emacs.  This supports one of the use cases I was interested in,
something I've run into a reasonable number of times.

The use case is this: suppose I install some package, for example ERC,
in my $HOME.  Then later I upgrade to Emacs 22, which includes ERC.
At this point I want my private ERC to be deactivated in favor of
Emacs' built-in version.  But then later I may upgrade to a later ERC,
in which case I want to use my newer private copy again.

In package.el this is solved by knowing the versions of large packages
which are included in Emacs.  This list isn't complete though -- known
bug.

David> Does your code also check for actually installed files?

Nope.  It could though, I think, perhaps not without drastically
slowing down Emacs startup.  I want to avoid that as much as possible.
I suppose my ideal situation here would be for distros to support
package.el directly (my real ideal was to get this into Emacs itself
but that is looking less likely :-).  This is intentionally not hard
to do... but I think it is still a bit early to approach them on this
topic.

Tom