Re: XEmacs package code

[Stefan Monnier]

> The main problem is that our package system identifies each package
> only by its name, and this is the only identifier you get for
> resolving dependencies.  However, packages change over time, and with
> change, incompatibilities arise, both with the user and with other
> packages.  (Out here, local users often request that a certain version
> of some package be version-frozen because they don't want to deal with
> bugs or changes in new versions.)
> 
> Unfortunately, the system of searching Lisp files in a global
> load-path is not equipped to deal with this problem, since it
> identifies only a single file foo.el (the first in a list of
> directories) where there may be several different ones.  Note that
> this is also tied to the current API for `provide' and `require.'

You obviously have a lot of experience with such a package system, so
I'd love to know more about the details and the reasons for those details.

I was imagining a system as follows:

Packages distributed as a directory (like url, w3, gnus, x-symbol, ...)
get installed into <prefix>/w3-3.0.45.  Packages distributed as a single
file get installed into <prefix>/<subdir>/<filename>.el(c)

The user then puts in his .emacs (and/or site-lisp/site-start.el) a set
of versioning options:

   (load "<prefix>/w3-3.0.44/autoloads")
   (load "<prefix>/subdir-beta/autoloads")

These "autoloads" file add their directory to the load-path and
setup the usual autoloads and auto-mode-alist kind of things.

So you can install several versions of packages and the user chooses
which one she wants.  For single-file-packages, she can only choose
on a group-of-packages basis, where the grouping is up to the installer.

Now this does not automatically handle the issue of "package X wants
version Y of package Z", but it lets the user take care of it.
And of course, if we assume that the (load "foobar/autoloads") commands
are added by the package-manager, the dependencies could still be
obeyed without the user having to do anything, as long as some kind
of dependency-description language like the one you propose is available
(but that would be a separate layer).

Alright, I haven't really asked too many questions, have I ?

I'm not sure what question I want to ask apart from
- is the above hopelessly flawed ?
- if not, does it look anything like what you have in mind ?
- what are the layer/decomposition you're considering ?
  there are obviously several issues:
  - package format when installing.
  - package format once installed.
  - representation of dependency.
  - who/when do we use the dependency info.
  - ...


        Stefan