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 10:43:58 -0600 Message-ID: <87vfck4569.fsf@trouble.defaultvalue.org> References: <1097949129.4178.31.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1099673082 10170 80.91.229.6 (5 Nov 2004 16:44:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Nov 2004 16:44:42 +0000 (UTC) Cc: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 05 17:44:30 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 1CQ7CP-000661-00 for ; Fri, 05 Nov 2004 17:44:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ7Kc-0005su-Bh for guile-devel@m.gmane.org; Fri, 05 Nov 2004 11:52:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQ7KU-0005sm-MF for guile-devel@gnu.org; Fri, 05 Nov 2004 11:52:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQ7KT-0005sX-FP for guile-devel@gnu.org; Fri, 05 Nov 2004 11:52:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ7KS-0005sT-Vf for guile-devel@gnu.org; Fri, 05 Nov 2004 11:52:49 -0500 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CQ7Bv-0006iS-SO for guile-devel@gnu.org; Fri, 05 Nov 2004 11:44:00 -0500 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id 52C8A3FF7; Fri, 5 Nov 2004 10:43:59 -0600 (CST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 063F4410AB; Fri, 5 Nov 2004 10:43:58 -0600 (CST) Original-To: Marius Vollmer In-Reply-To: (Paul Jarc's message of "Fri, 05 Nov 2004 10:25:02 -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:4337 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4337 prj@po.cwru.edu (Paul Jarc) writes: > I like this idea. But there should probably be a command-line > switch to disable loading these files. For a parallel example with > Emacs, sometimes there is a site installation of Gnus, and the site > init files load part of Gnus, but the user may have their own newer > copy of Gnus that they want to use. So they should be able to (and > with Emacs, they can) disable the normal loading of the site init > files, and then explicitly load them from their personal init file > after they've made the necessary load-path changes. Hmm. We were thinking of having guile load from ${sysconfdir}/guile-X.Y/init.d/. If the local version isn't installed in the same place as the site installation, then it wouldn't try to load the site's files by default. However, if you did want it to load them, you could just create a symlink to init.d, or make the init call yourself. Even so, perhaps a "--site-files DIR" option might be worth considering. > I'm not sure the two-digit requirement will be useful. Independent > packages won't know about each other, so they have no way to guess > the right order for their init files to be loaded in. They should > aim for order-independence. Then if it turns out there are ordering > problems, the admin can create earlier-named symlinks that fall in > the right order, and Guile can say "I've seen this device+inode > before, I won't load it again". (minor note: I had been thinking of one or more digits.) We were modeling this after the normal sysvinit and Debian emacsen approach. i.e. /etc/rcS.d/ and /etc/emacs/site-start.d/. Using NUMBERname makes it very easy to predict what's going to happen. With the device+inode+visited-table approach, you can't easily tell what's going to happen just by looking at the directory. On the other hand, I can see the concern that the NUMBERname approach is perhaps best suited for a situation where you have centralized organization (i.e. a distribution). We probably need a bit of further consideration here. As background, one of the original reasons for our proposed changes is to provide a standard place for distributions to put add-on package files (a la emacs/site-start.d/). The fact that this also lets us move the site initialization file (init.scm) to /etc/ (by reserving N*site-local.scm) is an added benefit that fixes a violation of the FHS. > That check would also let packages' init files load other init files > they depend on, which solves the ordering problem automatically, > without having to guess numbers. That might argue for a use-modules or require/provide style solution, though if appropriate, we'd want a modified one that only looks in the init.d dir so that startup files can't be confused with files in other packages (i.e. don't use load-path). -- 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