Re: Integrating package.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 04 Mar 2010 13:29:49 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I want to be able to install all kinds of versions in a single spot
SM> so I can quickly see which versions are available.  This said, I
SM> agree that allowing several install locations is desirable.

SM> Actually the "install" part of the code should be able to install
SM> a package *anywhere*.  Similarly, the activation of a package
SM> (i.e. setting up the autoloads) should be doable from a package located
SM> anywhere.

SM> It doesn't need to be part of the visible UI, but there should be
SM> a command like M-x package-install that takes a file name (a single .el
SM> file or a tarball) and a target directory (defaults to the main "install
SM> location") and installs it there.

SM> The only part that really needs to know about "install locations" is the
SM> part that lets you list all the installed packages, deinstall some of
SM> them, setup/remove activation for some of them, etc...

On Thu, 04 Mar 2010 11:30:26 -0700 Tom Tromey <tromey@redhat.com> wrote: 

Tom> You need multiple install locations to let package.el manage additions
Tom> in site-lisp, and also (maybe -- there are some questions here) the
Tom> load-path for packages which are included with Emacs but also released
Tom> separately.

Tom> So suppose Emacs starts up and sees, say, 3 versions of gnus: one
Tom> included in Emacs, one in site-lisp, and one in ~/.emacs.d/elpa/.
Tom> Which one should be activated?

Tom> Right now the obvious answer would be the newest one -- but Stefan wants
Tom> to let the user pick a specific one.  So, I think we'll need a bit of
Tom> additional metadata about this.

How about letting the user define his own install location for each
repository, but with a sensible default?  The location could also be
tagged with a "is it versioned?" boolean.  While installing may not be
possible into every location, the user will be able to activate whatever
is installed in any location.

For example:

ELPA's Gnus defaults to ~/.emacs.d/elpa
(from repository "ELPA", versioned to $location/gnus-x.yz )

Emacs' Gnus defaults to /usr/local/share/emacs/23.1/lisp
(from repository "emacs 23.1", unversioned to $location/gnus)

site's Gnus is set by user to /usr/local/share/oursite/lisp
(from user-defined repository "oursite", unversioned to $location/gnus)

So then "package-install" without a specific repository will pick the
first repository in the package-archives list and try to write to it.
If it fails, that's an error.  Similarly for package removal.

With a specific repository, both install and remove go to the specific
location set by the user.  Yes, unversioned install locations will cause
conflicts, but they are necessary to make this backwards compatible.

So then resolving the question of multiple installs will actually be

"Do you want to pick the ELPA Gnus [in ...], the Emacs 23.1 Gnus 
[in ...], the oursite Gnus [in ...], or this CVS checkout we found in
~/gnus/lisp because it was in your load-path?"

IOW, the user would choose between repository install locations
(represented by the name of the repository) and unmanaged paths to
resolve the conflict.  Would that work?

Ted