From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: Modified load-path proposal Date: Sun, 30 Oct 2005 18:04:58 +0000 Message-ID: <87u0ey3mph.fsf@ossau.uklinux.net> References: <878xwx5ld2.fsf@ossau.uklinux.net> <87u0fl3wam.fsf@ossau.uklinux.net> <87oe5s51l4.fsf@ivanova.rotty.yi.org> <87ek6njah0.fsf@ossau.uklinux.net> <87r7adf8h1.fsf@zip.com.au> <87vezhbknv.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1130695592 26742 80.91.229.2 (30 Oct 2005 18:06:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2005 18:06:32 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Oct 30 19:06:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EWHYP-0000ua-JI for guile-user@m.gmane.org; Sun, 30 Oct 2005 19:05:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EWHYO-0003AS-QU for guile-user@m.gmane.org; Sun, 30 Oct 2005 13:05:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EWHYK-0003AM-Gh for guile-user@gnu.org; Sun, 30 Oct 2005 13:05:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EWHYJ-0003AA-J4 for guile-user@gnu.org; Sun, 30 Oct 2005 13:05:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EWHYJ-0003A7-Cx for guile-user@gnu.org; Sun, 30 Oct 2005 13:05:07 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EWHYJ-0005TK-4Q for guile-user@gnu.org; Sun, 30 Oct 2005 13:05:07 -0500 Original-Received: from laruns (host81-130-88-151.in-addr.btopenworld.com [81.130.88.151]) by mail3.uklinux.net (Postfix) with ESMTP id A9B40409FAD for ; Sun, 30 Oct 2005 18:05:05 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 9F0F56F6CE for ; Sun, 30 Oct 2005 18:04:58 +0000 (GMT) Original-To: guile-user@gnu.org In-Reply-To: <87vezhbknv.fsf@ossau.uklinux.net> (Neil Jerram's message of "Fri, 28 Oct 2005 18:45:08 +0100") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4913 Archived-At: Neil Jerram writes: > So all that's left is: > > - config.scm, as previously described but with simpler format like > this: > > ((load-path > "/usr/share/guile/site" > "/usr/share/guile" > "/usr/share/guile/1.6" > ...) > ...) > > - Guile's reading of config.scm on startup, as previously described > (and respecting $sysconfdir) > > - guile-config ensure-load-path and guile-config clean-load-path, for > use at package author's discretion in Makefile.am. > > Everyone happy with that? Well, I'm not sure I am. This is still not quite nice, in that (i) editing config.scm when a 3rd party package is installed or removed is not as neat as just creating or deleting a file in an init.d style directory; (ii) there's no trace of why a load path directory is present in config.scm, i.e. which packages are relying on it. I've reviewed everything I'm aware of that's been written on this subject, starting from Marius's and Rob's original proposal at http://lists.gnu.org/archive/html/guile-devel/2004-11/msg00016.html, and I'm finally inclined to think that an init.d approach is nicer than a config.scm file that can be automatically edited. In the init.d approach, there would be a directory named $sysconfdir/guile/X.Y/init.d, and we would distribute an init.scm file (which Guile normally loads on startup) which would load all the files in $sysconfdir/guile/X.Y/init.d. So, for example, when a package guile-foo is installed under $prefix, it would create the file $sysconfdir/guile/X.Y/init.d/guile-foo with contents: (require-load-path-directory "$prefix/wherever/my/scheme/files/are") There was consensus in the previous discussion that a package should not do anything in such files except for load path modification. We could enforce this by making the contents instead: "$prefix/wherever/my/scheme/files/are" and making init.scm read the file instead of loading it, but that would mean that if we ever do think of something else that the init.d files should be able to do, we'd have to enhance the whole mechanism again. On balance I think it's best to load the init.d files (hence theoretically allowing arbitrary code) but make it clear by documentation/convention that only load path extension is expected. In comparison with the config.scm idea, the advantages are that you can immediately see from the contents of the init.d directory which packages are relying on particular load path directories (and, from the free software point of view, you can see where to go to find the scheme files for guile-foo), that there is no need for a heuristic to decide when to remove a directory, and that creating or deleting an init.d file is similar to what packaging systems already do when installing an add-on for other subsystems. Some other details from the past discussions ... 1. Whether init.scm is seen as belonging to Guile, to the distribution, or to the local sysadmin. It would be nice to put most of the code for the init.d system into boot-9.scm (or a file that boot-9.scm loads), so that init.scm can have just a one-liner which makes it all happen. (If we want to get sophisticated, there could be options to this one-liner to exclude the processing of particular packages, or to limit the set of packages that is processed to a named set, or to force an ordering ...) Then I think it is easy for either the distribution or the sysadmin to tweak init.scm as they need, but still clear how to get the "standard" Guile behaviour. 2. An option for suppressing the loading of init.scm. It seems straightforward that this is a good idea, like --no-site-file in Emacs. (Note that more finegrained selection - i.e. "run this part of init.scm but not that part" - can be implemented within the code of init.scm itself, if that is ever useful.) 3. Reading from $sysconfdir/guile/common/init.d as well as $sysconfdir/guile/X.Y/init.d, for packages that are not dependent on a particular Guile version. Seems like a good idea also. We could make the default one-liner invocation do this, put provide an option for more precise control if the distribution or sysadmin needs it. Finally, to be concrete about how this would end up looking in a 3rd party package's files, I think it would be something like this: ---8<---guile-foo.in---8<--- (require-load-path-directory "@-datadir-@/guile") ---8<---guile-foo.in---8<--- ---8<---Makefile.am---8<--- ... guileinitdir = @guileconfdir@/@GUILE_EFFECTIVE_VERSION@/init.d guileinit_DATA = guile-foo guile-foo: guile-foo.in sed -e "s,@-datadir-@,@datadir@,g" < $< > $@ ... ---8<---Makefile.am---8<--- And some autoconfery would be needed to make @guileconfdir@ expand to `guile-config info sysconfdir`/guile. Sorry to have been carrying on this discussion for so long, and for changing direction a couple of times. If anyone is still reading, I'd appreciate hearing your thoughts (again). Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user