Re: Modified load-path proposal

[Neil Jerram <neil@ossau.uklinux.net>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> So all that's left is:
>
> - config.scm, as previously described but with simpler format like
>   this:
>
>   ((load-path
>     "/usr/share/guile/site"
>     "/usr/share/guile"
>     "/usr/share/guile/1.6"
>     ...)
>    ...)
>
> - Guile's reading of config.scm on startup, as previously described
>   (and respecting $sysconfdir)
>
> - guile-config ensure-load-path and guile-config clean-load-path, for
>   use at package author's discretion in Makefile.am.
>
> Everyone happy with that?

Well, I'm not sure I am.  This is still not quite nice, in that (i)
editing config.scm when a 3rd party package is installed or removed is
not as neat as just creating or deleting a file in an init.d style
directory; (ii) there's no trace of why a load path directory is
present in config.scm, i.e. which packages are relying on it.

I've reviewed everything I'm aware of that's been written on this
subject, starting from Marius's and Rob's original proposal at
http://lists.gnu.org/archive/html/guile-devel/2004-11/msg00016.html,
and I'm finally inclined to think that an init.d approach is nicer
than a config.scm file that can be automatically edited.

In the init.d approach, there would be a directory named
$sysconfdir/guile/X.Y/init.d, and we would distribute an init.scm file
(which Guile normally loads on startup) which would load all the files
in $sysconfdir/guile/X.Y/init.d.  So, for example, when a package
guile-foo is installed under $prefix, it would create the file
$sysconfdir/guile/X.Y/init.d/guile-foo with contents:

(require-load-path-directory "$prefix/wherever/my/scheme/files/are")

There was consensus in the previous discussion that a package should
not do anything in such files except for load path modification.  We
could enforce this by making the contents instead:

"$prefix/wherever/my/scheme/files/are"

and making init.scm read the file instead of loading it, but that
would mean that if we ever do think of something else that the init.d
files should be able to do, we'd have to enhance the whole mechanism
again.  On balance I think it's best to load the init.d files (hence
theoretically allowing arbitrary code) but make it clear by
documentation/convention that only load path extension is expected.

In comparison with the config.scm idea, the advantages are that you
can immediately see from the contents of the init.d directory which
packages are relying on particular load path directories (and, from
the free software point of view, you can see where to go to find the
scheme files for guile-foo), that there is no need for a heuristic to
decide when to remove a directory, and that creating or deleting an
init.d file is similar to what packaging systems already do when
installing an add-on for other subsystems.

Some other details from the past discussions ...

1. Whether init.scm is seen as belonging to Guile, to the
   distribution, or to the local sysadmin.

   It would be nice to put most of the code for the init.d system into
   boot-9.scm (or a file that boot-9.scm loads), so that init.scm can
   have just a one-liner which makes it all happen.  (If we want to
   get sophisticated, there could be options to this one-liner to
   exclude the processing of particular packages, or to limit the set
   of packages that is processed to a named set, or to force an
   ordering ...)

   Then I think it is easy for either the distribution or the sysadmin
   to tweak init.scm as they need, but still clear how to get the
   "standard" Guile behaviour.

2. An option for suppressing the loading of init.scm.

   It seems straightforward that this is a good idea, like
   --no-site-file in Emacs.  (Note that more finegrained selection -
   i.e. "run this part of init.scm but not that part" - can be
   implemented within the code of init.scm itself, if that is ever
   useful.)

3. Reading from $sysconfdir/guile/common/init.d as well as
   $sysconfdir/guile/X.Y/init.d, for packages that are not dependent
   on a particular Guile version.

   Seems like a good idea also.  We could make the default one-liner
   invocation do this, put provide an option for more precise control
   if the distribution or sysadmin needs it.

Finally, to be concrete about how this would end up looking in a 3rd
party package's files, I think it would be something like this:

---8<---guile-foo.in---8<---
(require-load-path-directory "@-datadir-@/guile")
---8<---guile-foo.in---8<---

---8<---Makefile.am---8<---
...
guileinitdir = @guileconfdir@/@GUILE_EFFECTIVE_VERSION@/init.d
guileinit_DATA = guile-foo

guile-foo: guile-foo.in
	sed -e "s,@-datadir-@,@datadir@,g" < $< > $@
...
---8<---Makefile.am---8<---

And some autoconfery would be needed to make @guileconfdir@ expand to
`guile-config info sysconfdir`/guile.

Sorry to have been carrying on this discussion for so long, and for
changing direction a couple of times.  If anyone is still reading, I'd
appreciate hearing your thoughts (again).

     Neil



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