From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: The load path Date: Fri, 05 Nov 2004 16:05:40 -0600 Message-ID: <87lldgt0i3.fsf@trouble.defaultvalue.org> References: <1097949129.4178.31.camel@localhost> <87vfck4569.fsf@trouble.defaultvalue.org> <87actw15s9.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1099705153 23594 80.91.229.6 (6 Nov 2004 01:39:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 6 Nov 2004 01:39:13 +0000 (UTC) Cc: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 06 02:39:06 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CQFXl-0000UQ-00 for ; Sat, 06 Nov 2004 02:39:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQFfz-0001p1-F9 for guile-devel@m.gmane.org; Fri, 05 Nov 2004 20:47:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQFfK-00012Z-97 for guile-devel@gnu.org; Fri, 05 Nov 2004 20:46:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQFfI-00011U-Pq for guile-devel@gnu.org; Fri, 05 Nov 2004 20:46:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQFfI-00011B-Lu for guile-devel@gnu.org; Fri, 05 Nov 2004 20:46:52 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CQFWo-0004Gu-FS for guile-devel@gnu.org; Fri, 05 Nov 2004 20:38:06 -0500 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by mx20.gnu.org with esmtp (Exim 4.34) id 1CQCEF-0006CF-EU for guile-devel@gnu.org; Fri, 05 Nov 2004 17:06:43 -0500 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id 365A140D4; Fri, 5 Nov 2004 16:05:41 -0600 (CST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id D659C410AB; Fri, 5 Nov 2004 16:05:40 -0600 (CST) Original-To: Marius Vollmer In-Reply-To: (Paul Jarc's message of "Fri, 05 Nov 2004 14:22:30 -0500") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:4346 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4346 prj@po.cwru.edu (Paul Jarc) writes: > Hmm. ISTM modules are already good enough for everything except > tweaking %load-path, since that has to be done before the modules > can be found. But if that's the only problem that needs to be > solved, then there's a very simple solution: have a directory full > of subdirectories that all get added to %load-path. For a module > installed somewhere else, you can just drop a symlink in the central > directory, pointing to the module's directory. I'm still a little concerned that use-modules might be practically correct here, but semantically wrong, but I'm not sure yet. I'm also not sure that the init-require/provide approach is better. The question that troubles me is whether or not the "init-file" namespace should be separate from the normal module namespace. Overall, what I wanted was a way to specify a set of actions that will be taken at init time, where the ordering can be easily specified, where actions can be added and removed easily (i.e. by adding/removing files), and where the local admin has a well defined way to make at least some adjustments if necessary. All of these actions (the files) should be editable by the local admin, so they need to be placed in /etc according to the FHS (i.e. automake's sysconfdir). Further, at least for Debian, if they're in /etc, they must be conffiles, and so they may need to stick around and still function correctly (i.e. not break things) even if the underlying package has been removed. That's why in the emacs/site-start.d/* files, you will see conditional code like this: (if (not (file-exists-p "/usr/share/emacs/site-lisp/autoconf")) (message "Package autoconf removed but not purged. Skipping setup.") ... do the normal setup here which the admin might edit... ) Strictly speaking, the init files won't necessarily be modules, although we could perhaps use that mechanism, but the questions are, is it appropriate to use the module system for this, and should these files still be visible to other use-modules calls, even after startup is finished? If not, then we shouldn't use the module system directly, though we could probably share code. In any case, having some dependency mechanism, as you've suggested, wether it is use-modules or init-require/provide seems like a pretty good solution, allowing ordering without relying on the sorting of file names, and the local admin can still take some control by creating an /etc/guile-X.Y/init.scm file, or perhaps adding their own *-site-local.scm init.d files. I do think that init.scm should be explictly reserved for the local sysadmin (*not* for distributions). The sysadmin should be able to easily ignore (or filter) the distribution's init.d files if they so choose, and init.scm would be the place to do that. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel