guile-devel
[Top][All Lists]
Advanced

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

Re: The load path


From: Rob Browning
Subject: Re: The load path
Date: Sat, 06 Nov 2004 15:21:52 -0600
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Neil Jerram <address@hidden> writes:

> Yes, I understood that; I'm currently inclined against the proposal.

See my recent reply to Paul.  After some thinking, I'm similarly
inclined.

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

Agreed, with the one caveat that until/unless we end up with some
better module versioning support, we may need a bit of policy, at
least within distributions that support multiple installed versions of
Guile.

Imagine there's a guile add-on module package foo.  Also imagine that
it works fine with guile-1.6 and guile-1.8, but not guile-2.0.  It
needs to be able to arrange for itself to be available via
(use-modules (foo)) in the first two cases, but not in the last.

One easy way to do that with the current system would be to just tell
the add-on packages to put their files elsewhere (say /usr/share/foo)
and then set up the right symlinks during installation:

   /usr/share/guile/1.6/foo -> ../../foo
   /usr/share/guile/1.8/foo -> ../../foo

Of course Guile still needs better support for multiple installed
versions, presuming we're interested in such support upstream (bin/*
in particular).  Otherwise, I can continue to just work on that in
Debian.

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

I agree completely.

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




reply via email to

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