Re: The load path

[prj@po.cwru.edu (Paul Jarc)]

Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> In fact, the Debian approach is to have a directory of init files
> that all get executed in order, so that different packages can
> cleanly deposit their own actions.

I like this idea.  But there should probably be a command-line switch
to disable loading these files.  For a parallel example with Emacs,
sometimes there is a site installation of Gnus, and the site init
files load part of Gnus, but the user may have their own newer copy of
Gnus that they want to use.  So they should be able to (and with
Emacs, they can) disable the normal loading of the site init files,
and then explicitly load them from their personal init file after
they've made the necessary load-path changes.

In the more common case, the site init file won't cause any trouble,
and the personal init file ought to be able to depend on the site init
file - which is why the site init stuff should be loaded first, which
is why disabling it has to be done with a command line switch instead
of something in the personal init file.

>   (define (list-directory dir pattern)

(use-modules ((ice-9 ftw) :select (directory-files)))

> There can be additional rules about the contents of init.d/: Files
> with names matching *site-local.scm are reserved for the site admin.
> All filenames must start with at least two-digits, etc.

I'm not sure the two-digit requirement will be useful.  Independent
packages won't know about each other, so they have no way to guess the
right order for their init files to be loaded in.  They should aim for
order-independence.  Then if it turns out there are ordering problems,
the admin can create earlier-named symlinks that fall in the right
order, and Guile can say "I've seen this device+inode before, I won't
load it again".  That check would also let packages' init files load
other init files they depend on, which solves the ordering problem
automatically, without having to guess numbers.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel