Re: Another load path idea

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hi Neil,
>
> On Sat, 2006-01-21 at 09:01 +0000, Neil Jerram wrote:
>> Basically agreed, but what I now plan precisely is as follows.
>
> Oh good, a summary of this thread of many moons :)

I'm sorry it's gone on for so long.  Every time we appear to near a
consensus, some new issue pops up.

> A question though. What is the problem which is being solved here?

The basic scenario is this: someone has Guile installed (probably by
their distro) in /usr, and then builds and installs an additional
package using ./configure && make && sudo make install, which installs
with a different prefix than /usr (usually /usr/local).  Then they try
to do a (use-modules (newly-installed-package)), and it doesn't work,
because the installed Guile's load path doesn't include anything
beginning with /usr/local/share/guile.

So the question is: can we define a mechanism so that the use-modules
would just work?

Some time back, I thought that the right thing to do might be for the
package to discover the installed Guile's site directory and install
its modules there.  But there was a strong consensus that that was
wrong, and that when a package is configured with a given prefix, it
must install all its files under that prefix (except for config files
which go under the configured sysconfdir).

> In guile-gnome I only really use the load path in one place. That is
> that (use-modules (gnome-0)) adds the path for version 0 of the
> guile-gnome API to the load path. Before that you cannot import (gnome
> gobject), for example, because it's not in the path. Afterwards you
> can.

Then the question in your case would be how do you get the initial
(use-modules (gnome-0)) to work?

> This was done this way to allow me to break API in the future, but leave
> existing programs still working.
>
> In that sense a global path that adds gnome isn't terribly interesting,
> because you have to select the API version in the first place.

The way I see it, the global path would be the one that allowed
(use-modules (gnome-0)) or (use-modules (gnome-1)) to work.  It's fine
if (gnome-0) or (gnome-1) then extends the load path further.

>> 2. Each Guile package installs a file under /etc/guile which contains
>>    its load path as a single string.
>
> What about packages that depend on each other? Is that out of the scope
> of this proposal?

No; the idea is that each installed package does whatever is needed to
allow Guile (or any other Guile package) to bootstrap its modules.

> I assume you mean /etc/guile/$effective_version

Actually I meant to be vague, hence "under" :-).  My guess is that
many Guile packages are version-independent, so could install their
paths under /etc/guile/common.  Packages that know they are
version-dependent could install under one (or more)
$effective_version's.  I'm not really sure on the details here yet.

> I think requiring users to run a command to fix the cache is an
> invitation for bugs. I think it would be sufficient to have a cache in
> ~/.guile.d/cache, that would effectively hold the output of running
> guile-config. That way the normal case is that one only stats the cache,
> reads the system path dir, statting entries there, and then if
> everything is up to date just load the cache file. That's one readdir,
> one file read, and about 5 stats. Not expensive at all.

Sorry, I understand your overall idea about the cache, but I don't get
the details; can you be more precise about the reads and stats?

> Perhaps I'm just burned by the fiasco that was gstreamer's gst-register.
> Now having gotten rid of it, making the "registry" user-local and with
> strict cache semantics, we get no bugs about it.

That sounds like useful experience.  Can I go somewhere to read more
about it?

> Sorry to bring up issues this late in the game.

No problem; thanks for your input.

Regards,
     Neil