Re: Another load path idea

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> writes:

> Well, in the big picture of Guile package development, both of these
> concepts could be useful.  If I'm understanding you correctly, I would
> make the analogies that
>
> - a .la file is a bit like a formal list of all a package's
>   dependencies (which in practice might have to be declared by the
>   package author, or could be detected automatically by code analysis)
>
> - ld.so.conf is the environment information needed to be able to load
>   all those dependencies, which is distilled from the .la file.

Right.

> I'm imagining that the distillation process may take some time - in
> the worst case, for example, it could require searching the whole file
> system - and so it makes sense to do it once at package installation
> time and cache the ld.so.conf-like results.  I'm currently thinking of
> those results as just %load-path components, but they could (and
> probably should) be extended in future to cover LD_LIBRARY_PATH and/or
> the LTDL search path, for loading .so's.
>
> Overall, therefore, I'd say this idea is more about the ld.so.conf
> than about the .la files.  Perhaps with this expanded explanation
> you'd now agree?

I don't see `.la' files as a cache of `ld.so.conf'.  Libtool's `.la'
files are only used at compile-time, in order to find out library
dependencies, while `ld.so.conf' is used to locate dynamic libraries at
run-time, in a way similar to `%load-path'.

A dependency cache in Guile would make it possible to bypass
`%load-path'.  I.e., instead of `(load-from-path "some-file.scm")',
which needs to go through `%load-path', it would allow the right file to
be directly loaded as in `(load "/some/path/some-file.scm")'.  IOW, this
would be an /optimization/.

Personally, I don't think this optimization is worth it (more below).

> Those are both true, but in my mind (at least) there was one more
> factor, namely that it is not neat for every Guile application to
> start up with a load path that covers all installed Guile packages.
> It feels neater to me if each Guile application runs with exactly the
> environment that it needs.

You gave several good arguments against try to minimize `%load-path'.

In fact, I think that the optimization that consists of
minimizing/bypassing `%load-path' is not very valuable:

1. Practically, it seems that traversing even tens of directories to
   locate a file is cheap compared to actually evaluating code, and, for
   instance, marking and sweeping;  ;-)

2. Just like `$PATH', `$LD_LIBRARY_PATH' and the likes, `%load-path'
   should is not supposed to contain a lot of directories; currently, it
   contains 4 items by default, and I guess people will rarely have more
   than 10 items in it.

   For the record, in Debian, most (if not all) Python packages get
   installed in `/usr/lib/pythonX.X' and
   `/usr/lib/pythonX.X/site-packages'.  The same goes for Perl, etc.


As a conclusion, I'd still be in favor of a single file like this:

>> Or what about a single init file (again without any code, only data),
>> somewhat enhanced to keep track of which package rely on a each
>> particular load path:
>>
>>   ((guile-gnome . "/opt/guile-gnome/")
>>    (guile-chbouib . "/usr/local/share/guile-chbouib")
>>    ... )

At startup-time, Guile would simply:

  (set! %load-path
        (append (map cdr (with-input-from-file "config.scm" read))
                %load-path))

Actually, it's likely that several packages will rely on the same load
path, the format should rather be:

    (((guile-gnome) . "/opt/guile-gnome")
     ((guile-chbouib guile-foo guile-bar) . "/usr/local/share/guile")
     ... )

Then, we need a `guile-update-load-path' script that does the right
thing with this file at (un)installation-time.

Thanks,
Ludovic.