From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Newsgroups: gmane.emacs.devel Subject: Re: XEmacs package code Date: Mon, 22 Apr 2002 14:26:48 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <87zo07jhn0.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1019478524 15167 127.0.0.1 (22 Apr 2002 12:28:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2002 12:28:44 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16zcw0-0003wW-00 for ; Mon, 22 Apr 2002 14:28:44 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zcwh-0003wo-00 for ; Mon, 22 Apr 2002 14:29:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zcve-0004nI-00; Mon, 22 Apr 2002 08:28:22 -0400 Original-Received: from mx2.informatik.uni-tuebingen.de ([134.2.12.9]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16zcuB-0004gS-00; Mon, 22 Apr 2002 08:26:51 -0400 Original-Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 17F811063; Mon, 22 Apr 2002 14:26:48 +0200 (MST) Original-Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id g3MCQmx71048; Mon, 22 Apr 2002 14:26:48 +0200 (CEST) (envelope-from sperber) Original-To: Miles Bader In-Reply-To: <87zo07jhn0.fsf@tc-1-100.kawasaki.gol.ne.jp> (Miles Bader's message of "14 Apr 2002 08:36:19 +0900") Original-Lines: 73 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.5 (beets, i386-unknown-freebsd4.5) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3026 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3026 >>>>> "Miles" == Miles Bader writes: Miles> sperber@informatik.uni-tuebingen.de (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