From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.lisp.guile.devel Subject: Re: The load path Date: Fri, 05 Nov 2004 14:22:30 -0500 Organization: What did you have in mind? A short, blunt, human pyramid? Message-ID: 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 1099682594 6611 80.91.229.6 (5 Nov 2004 19:23:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Nov 2004 19:23:14 +0000 (UTC) Cc: guile-devel , Marius Vollmer Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 05 20:23:03 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 1CQ9fr-0002aQ-00 for ; Fri, 05 Nov 2004 20:23:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ9o4-00047b-64 for guile-devel@m.gmane.org; Fri, 05 Nov 2004 14:31:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQ9nu-00046J-59 for guile-devel@gnu.org; Fri, 05 Nov 2004 14:31:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQ9nt-00045g-2P for guile-devel@gnu.org; Fri, 05 Nov 2004 14:31:21 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ9ns-00045T-UV for guile-devel@gnu.org; Fri, 05 Nov 2004 14:31:21 -0500 Original-Received: from [129.22.104.47] (helo=mirapoint2.tis.cwru.edu) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CQ9fO-0000bu-Q7 for guile-devel@gnu.org; Fri, 05 Nov 2004 14:22:35 -0500 Original-Received: from multivac.cwru.edu (multivac.ITS.CWRU.Edu [129.22.114.26]) by mirapoint2.tis.cwru.edu (MOS 3.5.4-GR) with SMTP id CPE86066; Fri, 5 Nov 2004 14:22:31 -0500 (EST) Original-Received: (qmail 23025 invoked by uid 500); 5 Nov 2004 19:22:53 -0000 Original-To: Rob Browning In-Reply-To: <87actw15s9.fsf@trouble.defaultvalue.org> (Rob Browning's message of "Fri, 05 Nov 2004 12:59:02 -0600") Mail-Copies-To: nobody Mail-Followup-To: Rob Browning , Marius Vollmer , guile-devel Original-Lines: 56 User-Agent: Gnus/5.110003 (No Gnus v0.3) 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:4344 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4344 Rob Browning wrote: > Ahh, so you don't mean the case where the user installed their own > copy of guile. Right - the user just installs a newer version of a module. (Like installing a new Gnus, but still using the system Emacs.) > Having both options might make sense, i.e. --disable-init-dir and > "--init-dir DIR". Sure. >> Maybe best practice would be to put the initialization code in a >> normal module called (foo init), and then the init file merely loads >> that module. > > Hmm, but that won't allow the init file to set up the %load-path if > needed, i.e. Ah, right. 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. So first augment %load-path unconditionally; then load the site init code (optional, default yes); then load the user init code (optional, default yes). > It also still doesn't leave any way for the local admin to specify > configurations that are guaranteed to run at a particular time without > modifying all the other init files. Let Guile load a site init file by default. Distros will create that file, and they can have it load a local-admin init file at the appropriate spot (maybe even one at the beginning and one at the end). People installing from source will create the site init file themselves, since there's no distro sitting between them and Guile. > This approach would allow dependencies without conflating > initialization and the normal module namespace, What sort of init code needs to be handled, other than %load-path tweaking? > and it seems like it would allow the local admin a reasonable level > of control. Yes, I'd say your approach is flexibile enough. paul _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel