Re: Integrating package.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 08 Mar 2010 12:01:52 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

Tom> I think the default should be to activate the most recent package, and
Tom> to activate a package at install time.  So, if the user picks a specific
Tom> older version to activate (or equivalently deactivates the most recent
Tom> version), record that, and take it into account during activation.

>> So it's a version override alist, where a missing entry implies the user
>> wants the latest?  Do you mean something like this:

>> ((package1 (repository1 path-to-specific-version1)) 
>> (package2 (repository2 path-to-specific-version2)))

>> or am I misunderstanding something?

SM> Don't know about you, but I seem to be missing something: why is the
SM> word "repository" used here?  AFAIK the "repository" for package.el are
SM> (typically remote) locations from where to download packages, and they
SM> should have no interaction whatsoever with the part that worries about
SM> installation and activation of packages (just like Debian's dpkg has no
SM> idea about repositories).

I thought it made sense to remember the repository that a particular
version came from, so selection (for activation) and warning messages
are more helpful.  But this can be guessed based on the path prefix so
it's not strictly necessary, and you seem to be looking for package
management that's less tied to repositories anyhow.  So forget the above
and see if the following makes sense.

SM> BTW, my take on package activation and selection of versions (which IIRC
SM> I already discussed with Tom a while back and we agreed to disagree) is
SM> that activation of a package is controlled by lines in .emacs that take
SM> a form similar to:

SM>    (load "/some/where/package/init/file.el" 'package)

SM> so there is no search or selection of package version at startup-time.

SM> This means that when a new version of a package is installed, Emacs has
SM> various ways to react to it:
SM> - don't do anything, and at the next startup warn the user that the
SM>   package he requested doesn't exist any more because it was replaced by
SM>   a new version.

This warning is always necessary because packages can get removed by
external agents as well (so the user doesn't know the load path is
incorrect).  So there could be no new version at all.

SM> - update the "load" line right when the package gets upgraded (tho only
SM>   for the .emacs of the user that performs the upgrade).

Too many potential problems here, I'd stay away from this.

SM> - use symlinks like "/some/where/elisp/sml-mode" pointing to
SM>   "sml-mode-4.1" and use (load "/some/where/elisp/sml-mode/startup.el")
SM>   so the symlink can be adjusted during the upgrade.

I did this for 7 years in a lab I was managing and it's not fun.  You
can automate some of the tedium but inevitably it becomes unwieldy.
If the user or admin wants to do it this way, let them manage it
externally, there are decent tools to automate it or they can write
ELisp wrappers to fit their environment.

Also symlinks don't work reliably in some environments.

SM> - use a different load, like

SM>    (package-activate-latest "/some/where/elisp/sml-mode")

SM>   which will look for the latest sml-mode package installed in
SM>   /some/where/elisp/, or

SM>    (package-activate-latest "sml-mode")

SM>   which will look for the latest sml-mode package installed in
SM>   any of the installation targets.

For the sake of backward compatibility this seems like the best option.
(load) and (require) can keep working normally.  Users can then
transition to the package.el management gradually.  Emacs can start
using these options gradually too.

Version overrides can be then specified as

(package-activate-specific "sml-mode" "specific-version")
(package-activate-specific "/path/to/sml-mode" "specific-version")

Together with the startup warnings (which can be issued by
package-activate-{specific,latest}) I think this approach makes sense.

Ted