guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The load path


From: Neil Jerram
Subject: Re: The load path
Date: Sat, 06 Nov 2004 17:49:34 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

Rob Browning wrote:

Neil Jerram <address@hidden> 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]