From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: The load path Date: Sat, 06 Nov 2004 17:49:34 +0000 Message-ID: <418D0EAE.40703@ossau.uklinux.net> References: <1097949129.4178.31.camel@localhost> <418C126D.5010802@ossau.uklinux.net> <87u0s3r30n.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099774727 23991 80.91.229.6 (6 Nov 2004 20:58:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 6 Nov 2004 20:58:47 +0000 (UTC) Cc: Marius Vollmer , guile-devel , Greg Troxel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 06 21:58:40 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 1CQXdv-0002E2-00 for ; Sat, 06 Nov 2004 21:58:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQXmB-0003Ma-Lp for guile-devel@m.gmane.org; Sat, 06 Nov 2004 16:07:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQXl3-0002XR-Rh for guile-devel@gnu.org; Sat, 06 Nov 2004 16:06:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQXl2-0002Wr-NX for guile-devel@gnu.org; Sat, 06 Nov 2004 16:06:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQXl2-0002Wn-Lh for guile-devel@gnu.org; Sat, 06 Nov 2004 16:06:00 -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 1CQXcd-00038h-VU for guile-devel@gnu.org; Sat, 06 Nov 2004 15:57:20 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by mx20.gnu.org with esmtp (Exim 4.34) id 1CQUm9-0007Zw-Pm for guile-devel@gnu.org; Sat, 06 Nov 2004 12:54:58 -0500 Original-Received: from laruns (host81-130-105-202.in-addr.btopenworld.com [81.130.105.202]) by mail3.uklinux.net (Postfix) with ESMTP id 02475409FA3; Sat, 6 Nov 2004 17:50:48 +0000 (UTC) Original-Received: from ossau.uklinux.net (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id BD6256FA10; Sat, 6 Nov 2004 17:49:34 +0000 (GMT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en Original-To: Rob Browning In-Reply-To: <87u0s3r30n.fsf@trouble.defaultvalue.org> 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:4353 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4353 Rob Browning wrote: >Neil Jerram writes: > > > >>I agree. It seems to me that the only thing we need to support here >>is %load-path extension, and that we might find a neater solution by >>focussing only on that problem (as opposed to a means for executing >>arbitrary 3rd party code at startup time). Guile has important >>differences here from Emacs, so it doesn't follow that a good design >>for Emacs is also good for Guile. >> >> > >One of the simlplest solutions > For which problem, though? > is to load all the files in a >well-specified /etc dir in some order. That's what Marius proposed, >and that's what Debian tends to do, both with Emacs, and with various >other things (ppp, ifup, cron, rc.?, etc.). > > Yes, I understood that; I'm currently inclined against the proposal. In my view, the Emacs analogy doesn't apply, because - Emacs is a user-focussed application where it is desirable for `M-x whatnot' to Just Work - Guile is a developer-focussed application where explicit-ness is more important than automatic-ness, so it is preferable to require a script or an interactive user to say (use-modules (whatnot)) (whatnot) The ppp/ifup/cron analogy doesn't apply because these are all invoked automatically by the system without user intervention. Guile on the other hand is always driven by a script, a specific program within which it is embedded, or by an interactive user; all of which have excellent existing mechanisms for executing any startup code that is needed for that particular use. >Paul then suggested that you might want to consider using dependencies >of some sort rather than just relying on a globally coordinated >ordering of file names. > This is a good consideration if you accept the premise that it is desirable to execute arbitrary code here. If you don't (which is my position), then it instead points to the dangers of adding unnecessary complexity. > I can see the argument in favor of that too, >though it would be less relevant if you're going to specify that these >files are only allowed to modify the %load-path. > > > Absolutely. %load-path ordering _could_ be important, but in my view we would have messed up if we allowed it to become so - see notes below on conflicts. Here's how I think this area should work. - On a non-distribution-managed machine, it is the machine admin's responsibility to set the needed %load-path in init.scm. - On a distribution-managed machine... - The set of %load-path directories is a distribution decision, not a per-package decision. In general, I think applications should be strongly encouraged to install their Scheme code in one of the distribution-wide %load-path locations, not in some application-specific directory (which would then need to be added to %load-path). This is good for free software - because people can find the code more easily, and see it in context - and good for forcing us to deal with any naming conflicts properly instead of hiding them under the carpet. - There is a handful of meta-packages (e.g. KDE, Gnome) that are so big that it might make sense for them to have their own %load-path location. But these are few enough that the distribution can include these in the distribution-wide %load-path from the start, even if those meta-packages are not actually installed. - Note that there is no need for a distribution mechanism to include /usr/local in the %load-path, system-wide, because the distribution does not use /usr/local. If the sysadmin knows that the machine also contains non-distribution-managed software in /usr/local, he/she can of course add /usr/local to the load path in init.scm. If a particular user wants /usr/local, he/she can extend the load path in their .guile. - Therefore a distribution can simply provide an init.scm that includes the distribution-wide load path. init.scm can be treated as a conf file in the usual Debian way (i.e. not automatically overwriting it if the local admin has changed it, and so on). I see no utility in doing something like adding all subdirs of a given directory to the load path. use-modules already uses a hierarchical namespace, so instead the subdir name should be the first component of the module name. I wonder if the real concerns here are of conflicts in module naming, and of handling different versions of the same module; both of which concerns would motivate being able to manipulate the load path so that the ordering of directories in it was important. In my view, relying on the ordering of load path components is the way of madness (except in the particular-user-experimenting mode, where a user prepends their own directory to the load path in order to experiment), and it would be far better to agree guidelines for unique module names, and to work out a solution for module versioning. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel