Re: Modified load-path proposal

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

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

> [... initialize-packages vs. config.scm approach ...]

I just thought of one more argument that favours initialize-packages,
namely that initialize-packages allows execution of arbitrary code to
initialize a package (whereas config.scm would only modify
%load-path), and that's bound to be useful sooner or later.

One example is the (gnome-0) module that guile-gnome installs in
/usr/share/guile/site, and which modifies %load-path (to point to the
rest of the install under /usr/share/guile-gnome-0) and
LD_LIBRARY_PATH.  This unusual arrangement prevented me from loading
guile-gnome at first, because I was using /usr/local/bin/guile, which
doesn't have /usr/share/guile/site in its load path.  If the stuff in
(gnome-0) was instead installed under /etc/guile/packages, it would
work in principle for both /usr/bin/guile and /usr/local/bin/guile.

Then, if we allow that guile-gnome has to munge LD_LIBRARY_PATH in
(gnome-0), i.e. outside of its main installed module tree, we have to
go with the initialize-packages approach.  In fact guile-gnome
_doesn't_ have to do this, so its not an open and shut case.  (It
could move the LD_LIBRARY_PATH code to a module in the main tree, and
make sure that this module is always used before any that depend on
LD_LIBRARY_PATH.)  But it makes sense to munge the load path and
LD_LIBRARY_PATH in the same place, so I'd say this is a good argument
for the initialize-packages approach and for allowing arbitrary code
execution.

Regards,
        Neil



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