Re: The load path

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

Rob Browning <rlb@defaultvalue.org> wrote:
> Ahh, so you don't mean the case where the user installed their own
> copy of guile.

Right - the user just installs a newer version of a module.  (Like
installing a new Gnus, but still using the system Emacs.)

> Having both options might make sense, i.e. --disable-init-dir and
> "--init-dir DIR".

Sure.

>> Maybe best practice would be to put the initialization code in a
>> normal module called (foo init), and then the init file merely loads
>> that module.
>
> Hmm, but that won't allow the init file to set up the %load-path if
> needed, i.e.

Ah, right.

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.

So first augment %load-path unconditionally; then load the site init
code (optional, default yes); then load the user init code (optional,
default yes).

> It also still doesn't leave any way for the local admin to specify
> configurations that are guaranteed to run at a particular time without
> modifying all the other init files.

Let Guile load a site init file by default.  Distros will create that
file, and they can have it load a local-admin init file at the
appropriate spot (maybe even one at the beginning and one at the end).
People installing from source will create the site init file
themselves, since there's no distro sitting between them and Guile.

> This approach would allow dependencies without conflating
> initialization and the normal module namespace,

What sort of init code needs to be handled, other than %load-path
tweaking?

> and it seems like it would allow the local admin a reasonable level
> of control.

Yes, I'd say your approach is flexibile enough.


paul


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