Re: The load path

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

Rob Browning wrote:

>Neil Jerram <neil@ossau.uklinux.net> writes:
>
>  
>
>>I agree. It seems to me that the only thing we need to support here
>>is %load-path extension, and that we might find a neater solution by
>>focussing only on that problem (as opposed to a means for executing
>>arbitrary 3rd party code at startup time). Guile has important
>>differences here from Emacs, so it doesn't follow that a good design
>>for Emacs is also good for Guile.
>>    
>>
>
>One of the simlplest solutions
>
For which problem, though?

> is to load all the files in a
>well-specified /etc dir in some order.  That's what Marius proposed,
>and that's what Debian tends to do, both with Emacs, and with various
>other things (ppp, ifup, cron, rc.?, etc.).
>  
>
Yes, I understood that; I'm currently inclined against the proposal.

In my view, the Emacs analogy doesn't apply, because

- Emacs is a user-focussed application where it is desirable for `M-x 
whatnot' to Just Work

- Guile is a developer-focussed application where explicit-ness is more 
important than automatic-ness, so it is preferable to require a script 
or an interactive user to say

  (use-modules (whatnot))
  (whatnot)

The ppp/ifup/cron analogy doesn't apply because these are all invoked 
automatically by the system without user intervention.  Guile on the 
other hand is always driven by a script, a specific program within which 
it is embedded, or by an interactive user; all of which have excellent 
existing mechanisms for executing any startup code that is needed for 
that particular use.

>Paul then suggested that you might want to consider using dependencies
>of some sort rather than just relying on a globally coordinated
>ordering of file names.
>
This is a good consideration if you accept the premise that it is 
desirable to execute arbitrary code here.  If you don't (which is my 
position), then it instead points to the dangers of adding unnecessary 
complexity.

>  I can see the argument in favor of that too,
>though it would be less relevant if you're going to specify that these
>files are only allowed to modify the %load-path.
>
>  
>
Absolutely.  %load-path ordering _could_ be important, but in my view we 
would have messed up if we allowed it to become so - see notes below on 
conflicts.

Here's how I think this area should work.

- On a non-distribution-managed machine, it is the machine admin's 
responsibility to set the needed %load-path in init.scm.

- On a distribution-managed machine...

  - The set of %load-path directories is a distribution decision, not a 
per-package decision.  In general, I think applications should be 
strongly encouraged to install their Scheme code in one of the 
distribution-wide %load-path locations, not in some application-specific 
directory (which would then need to be added to %load-path).  This is 
good for free software - because people can find the code more easily, 
and see it in context - and good for forcing us to deal with any naming 
conflicts properly instead of hiding them under the carpet.

  - There is a handful of meta-packages (e.g. KDE, Gnome) that are so 
big that it might make sense for them to have their own %load-path 
location.  But these are few enough that the distribution can include 
these in the distribution-wide %load-path from the start, even if those 
meta-packages are not actually installed.

  - Note that there is no need for a distribution mechanism to include 
/usr/local in the %load-path, system-wide, because the distribution does 
not use /usr/local.  If the sysadmin knows that the machine also 
contains non-distribution-managed software in /usr/local, he/she can of 
course add /usr/local to the load path in init.scm.  If a particular 
user wants /usr/local, he/she can extend the load path in their .guile.

  - Therefore a distribution can simply provide an init.scm that 
includes the distribution-wide load path.  init.scm can be treated as a 
conf file in the usual Debian way (i.e. not automatically overwriting it 
if the local admin has changed it, and so on).

I see no utility in doing something like adding all subdirs of a given 
directory to the load path.  use-modules already uses a hierarchical 
namespace, so instead the subdir name should be the first component of 
the module name.  I wonder if the real concerns here are of conflicts in 
module naming, and of handling different versions of the same module; 
both of which concerns would motivate being able to manipulate the load 
path so that the ordering of directories in it was important.  In my 
view, relying on the ordering of load path components is the way of 
madness (except in the particular-user-experimenting mode, where a user 
prepends their own directory to the load path in order to experiment), 
and it would be far better to agree guidelines for unique module names, 
and to work out a solution for module versioning.

Regards,
    Neil




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