[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XEmacs package code
From: |
Stefan Monnier |
Subject: |
Re: XEmacs package code |
Date: |
Sun, 19 May 2002 19:51:45 -0400 |
> 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
- Re: XEmacs package code,
Stefan Monnier <=