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 12:59:02 -0600 Message-ID: <87actw15s9.fsf@trouble.defaultvalue.org> References: <1097949129.4178.31.camel@localhost> <87vfck4569.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 1099681187 2270 80.91.229.6 (5 Nov 2004 18:59:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Nov 2004 18:59:47 +0000 (UTC) Cc: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 05 19:59:29 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 1CQ9J3-0000YS-00 for ; Fri, 05 Nov 2004 19:59:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ9RG-0003fX-K7 for guile-devel@m.gmane.org; Fri, 05 Nov 2004 14:07:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQ9R9-0003fJ-Fy for guile-devel@gnu.org; Fri, 05 Nov 2004 14:07:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQ9R8-0003ep-3N for guile-devel@gnu.org; Fri, 05 Nov 2004 14:07:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ9R7-0003em-WD for guile-devel@gnu.org; Fri, 05 Nov 2004 14:07:50 -0500 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CQ9Id-00054S-Sf for guile-devel@gnu.org; Fri, 05 Nov 2004 13:59:04 -0500 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id EFB4A40D4; Fri, 5 Nov 2004 12:59:02 -0600 (CST) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id B8C9A410AB; Fri, 5 Nov 2004 12:59:02 -0600 (CST) Original-To: Marius Vollmer In-Reply-To: (Paul Jarc's message of "Fri, 05 Nov 2004 12:43:39 -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:4341 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4341 prj@po.cwru.edu (Paul Jarc) writes: > I'm thinking of the case where a user wants to avoid something the > admin put in the init code, or insert some other code ahead of it. > The user can't touch the sitewide init directory, so it can only be > controlled on the command line. Ahh, so you don't mean the case where the user installed their own copy of guile. Ok, then for that, --disable-init-d might be good, though "--init-dir /dev/null" might work too ;> Having both options might make sense, i.e. --disable-init-dir and "--init-dir DIR". >> 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). > > 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. init.d/package-a.scm: (use-modules (b init)) init.d/package-b.scm: (set! %load-path (cons ... %load-path)) ... So package-a's init will fail if it is run first. I also think we may need at least enough documented convention that the local admin can easily have a place to put their customizations, and can have sufficient control over when they are run. An alternate specification would be to require the init files to be modules named (init.d foo), and just arrange for ${siteconfdir}/guile-X.Y/ to be first in the %load-path before guile starts processing. So package foo would install guile-X.Y/init.d/foo.scm. However I'm still a little unsure about crowding the init process directly into the module namespace. Perhaps that's the right thing, but I'm not convinced yet. It would mean that we'd have to reserve a namespace like (init.d ...) and it would mean that all of the (init.d foo) modules would be visible to normal, non-init code, and there's no reason for that. 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. Here's a possible alternative: - specify ${siteconfdir}/guile-X.Y/init.d/ for "add-ons". - add a new bit of infrastructure. A trivial guile module called something like (guile init) which provides: (guile-run-initialization . dir) ;; load INITDIR/* in order. (guile-init-require name) ;; load INITDIR/name.scm iff not loaded (guile-init-provide name) ;; called by INITDIR/name.scm on success - have guile look for ${siteconfdir}/guile-X.Y/init.scm at startup. If that isn't found, then have it run (guile-run-initialization "${siteconfdir}/guile-X.Y/init.d"). However, if ${siteconfdir}/guile-X.Y/init.scm is found, guile just runs that. So if the local admin creates an init.scm, then they need to add this to the file (use-modules (guile init)) (guile-run-initialization "${siteconfdir}/guile-X.Y/init.d") if they want the normal startup behavior. We'll also provide a skeleton init.scm to demonstrate this in our documentation. - add "--confdir DIR" and --disable-init command line options. This approach would allow dependencies without conflating initialization and the normal module namespace, and it seems like it would allow the local admin a reasonable level of control. -- 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