Re: XEmacs package code

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Miles" == Miles Bader <address@hidden> writes:

Miles> address@hidden (Michael Sperber [Mr.  Preprocessor]) writes:
>> the current design of the package system is generally perceived as a
>> failure in the XEmacs community, even by Steve.  (I'll be happy to
>> explain why if anyone's interested.)

Miles> Please do...

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.'

So we really need an infrastructure that deals with versioning and
allows you to express requirements like "version x of package z" or
"any version after x of package z" or "any version of package z
between x and y" and so on.   This extends to the underlying Emacs for
which you also want to express dependencies.  Currently, this kind of
stuff is done inside the packages with a bunch of `boundp' calls or
other clever ESP hackery to figure out what other packages you're
actually dealing with.  Instead, there should be a declarative way
which allows you (without forcing you) to specify what you want or
what you have.

Moreover, you would like to be able to have a single package tree
which allows you to keep several versions of a single package
accessible to be more flexible fulfilling those requirements.  (Of
course, not all requirements are fulfillable---you usually can't
simultaneously load two versions of the same package, for example.
because Emacs Lisp lacks a proper module system.  It used to be you
couldn't load vc and vc-cc at the same time, and so on.  But you'd
like to be able to try and find out if it's possible.)

Therefore, the design draft allows you to annotate your existing
package with requirements, and there's a little compositional language
for specifying them.  If you don't do this, you'll still essentially
get the old functionality.  It also allows the user to say: When, at
some point in the future, I'll request package x to be loaded, I want
version y.  (Or express some more complicated requirement.)

>> I have designed a new one, but have not been able to spend much time
>> on implementing it.  Once I do, I'll try my best to make the code
>> modular and sharable between the Emacsen.

Miles> Do you have documents or notes about the new design too?

There's a thread at

http://list-archive.xemacs.org/xemacs-beta/199907/msg00143.html

whose root has some notes.  I'll be happy to flesh out particular
issues if anyone's interested.

Interested readers might also want to look at SRFI 7

http://srfi.schemers.org/srfi-7/

which uses similar ideas (which I formulated around the same time) for
a related purpose.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla