Re: The load path

[Rob Browning <rlb@defaultvalue.org>]

prj@po.cwru.edu (Paul Jarc) writes:

> Hmm.  ISTM modules are already good enough for everything except
> tweaking %load-path, since that has to be done before the modules
> can be found.  But if that's the only problem that needs to be
> solved, then there's a very simple solution: have a directory full
> of subdirectories that all get added to %load-path.  For a module
> installed somewhere else, you can just drop a symlink in the central
> directory, pointing to the module's directory.

I'm still a little concerned that use-modules might be practically
correct here, but semantically wrong, but I'm not sure yet.  I'm also
not sure that the init-require/provide approach is better.  The
question that troubles me is whether or not the "init-file" namespace
should be separate from the normal module namespace.

Overall, what I wanted was a way to specify a set of actions that will
be taken at init time, where the ordering can be easily specified,
where actions can be added and removed easily (i.e. by adding/removing
files), and where the local admin has a well defined way to make at
least some adjustments if necessary.

All of these actions (the files) should be editable by the local
admin, so they need to be placed in /etc according to the FHS
(i.e. automake's sysconfdir).  Further, at least for Debian, if
they're in /etc, they must be conffiles, and so they may need to stick
around and still function correctly (i.e. not break things) even if
the underlying package has been removed.  That's why in the
emacs/site-start.d/* files, you will see conditional code like this:

  (if (not (file-exists-p "/usr/share/emacs/site-lisp/autoconf"))
      (message "Package autoconf removed but not purged.  Skipping setup.")
    ... do the normal setup here which the admin might edit...
    )

Strictly speaking, the init files won't necessarily be modules,
although we could perhaps use that mechanism, but the questions are,
is it appropriate to use the module system for this, and should these
files still be visible to other use-modules calls, even after startup
is finished?  If not, then we shouldn't use the module system
directly, though we could probably share code.

In any case, having some dependency mechanism, as you've suggested,
wether it is use-modules or init-require/provide seems like a pretty
good solution, allowing ordering without relying on the sorting of
file names, and the local admin can still take some control by
creating an /etc/guile-X.Y/init.scm file, or perhaps adding their own
*-site-local.scm init.d files.

I do think that init.scm should be explictly reserved for the local
sysadmin (*not* for distributions).  The sysadmin should be able to
easily ignore (or filter) the distribution's init.d files if they so
choose, and init.scm would be the place to do that.

-- 
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