Re: The load path

[Rob Browning <rlb@defaultvalue.org>]

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

> I'm thinking of the case where a user wants to avoid something the
> admin put in the init code, or insert some other code ahead of it.
> The user can't touch the sitewide init directory, so it can only be
> controlled on the command line.

Ahh, so you don't mean the case where the user installed their own
copy of guile.  Ok, then for that, --disable-init-d might be good,
though "--init-dir /dev/null" might work too ;>

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

>> That might argue for a use-modules or require/provide style solution,
>> though if appropriate, we'd want a modified one that only looks in the
>> init.d dir so that startup files can't be confused with files in other
>> packages (i.e. don't use load-path).
>
> 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.

  init.d/package-a.scm: (use-modules (b init))

  init.d/package-b.scm: (set! %load-path (cons ... %load-path)) ...

So package-a's init will fail if it is run first.

I also think we may need at least enough documented convention that
the local admin can easily have a place to put their customizations,
and can have sufficient control over when they are run.

An alternate specification would be to require the init files to be
modules named (init.d foo), and just arrange for
${siteconfdir}/guile-X.Y/ to be first in the %load-path before guile
starts processing.  So package foo would install
guile-X.Y/init.d/foo.scm.

However I'm still a little unsure about crowding the init process
directly into the module namespace.  Perhaps that's the right thing,
but I'm not convinced yet.  It would mean that we'd have to reserve a
namespace like (init.d ...)  and it would mean that all of the (init.d
foo) modules would be visible to normal, non-init code, and there's no
reason for that.

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.

Here's a possible alternative:

  - specify ${siteconfdir}/guile-X.Y/init.d/ for "add-ons".

  - add a new bit of infrastructure.  A trivial guile module called
    something like (guile init) which provides:

      (guile-run-initialization . dir) ;; load INITDIR/* in order.
      (guile-init-require name) ;; load INITDIR/name.scm iff not loaded
      (guile-init-provide name) ;; called by INITDIR/name.scm on success

  - have guile look for ${siteconfdir}/guile-X.Y/init.scm at startup.
    If that isn't found, then have it run (guile-run-initialization
    "${siteconfdir}/guile-X.Y/init.d").

    However, if ${siteconfdir}/guile-X.Y/init.scm is found, guile just
    runs that.  So if the local admin creates an init.scm, then they
    need to add this to the file

      (use-modules (guile init))
      (guile-run-initialization "${siteconfdir}/guile-X.Y/init.d")

    if they want the normal startup behavior.  We'll also provide a
    skeleton init.scm to demonstrate this in our documentation.

  - add "--confdir DIR" and --disable-init command line options.

This approach would allow dependencies without conflating
initialization and the normal module namespace, and it seems like it
would allow the local admin a reasonable level of control.

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