Just a little note to say that I've been following along and am glad this 
is being discussed - and of course a few comments.

On Sat, 7 Jan 2006, Neil Jerram wrote:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> How so?  Given that you're about to do a (use-modules (whatnot)), I
>>> can't see that also doing (initialize-packages "whatnot") will make a
>>> significant difference.
>>
>> Because people haven't been doing so for years.  Some of us certainly
>> don't want to iterate over each and every Guile module to add this line.

I agree that an addition to the module-using or module-declaring 
forms should be avoided.

>> This is based on the observation that (i) we want modules to be
>> installable in *any* directory, but (ii) at some point, there must be a
>> *fixed* directory to look for files to bootstrap further file loading.

This general guideline seems to be on the right track:
Lots of tools seem to have grown foo.conf.d directories, probably because 
they're friendly to package managers.

Would a survey of conventions for such configuration-directories and how 
they work be fruitful?  One thing I notice is that systems where
performance is important seem to "compile" the contents of the config 
directory into a single file which can be read rapidly.
Examples are /ld.so.conf.d incorporated into ld.so.cache by ldconfig,
and Debian's update-modules building /etc/modules.conf from /etc/modutils.

The guile analogy might be guile-config (a program run by 
package-post-install scripts) collecting %load-path fragments from 
$prefix/etc/guile-conf.d/* into $prefix/share/guile/config.scm
(where $prefix is the prefix that guile was built with).

guile-config could be little more than cat, or could do more complex 
validation of the contents of each file in the config directory.  Likely 
it should remove duplicate %load-path entries, at least.  But the scanning 
of the directory is done only when needed, when a package containing a 
guile module is added or removed.

Important details to address:
- how to control the order in which things appear in %load-path
- how to make this play well with multiple versions of guile installed on 
the same system.


> It seems to me that neither of these ideas (yours and mine) quite fly
> yet.  I have yet another idea, though, that I'll post in a separate
> thread shortly.

I'll look for that and keep reading.  Thanks for thinking about this.

My interest in part comes from maintaining a package that uses guile and 
guile-gtk.  It seems that most of my users' problems come when they try to 
install guile-gtk from source (into /usr/local) but have guile installed 
from their linux distribution (in /usr).
My advice to date is generally to always install guile-gtk and guile in 
the same way: either both from source (say into /usr/local) or to build 
and install both using their package manager.  Or else to become wizards 
at setting up the right environment variables.
But it would be nice if the more common case would just work.

Steve