Re: Another load path idea

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> Hi,

Hi, and thanks for your input.

> Yes, but I think that's (almost) a different issue.  I think it solves
> the issue of finding the right dependency, not that of finding the right
> module.  IOW, it's similar to Libtool's `.la' files (which include
> information about a library's dependencies), not to /etc/ld.so.conf .

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.

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?

> Speaking of that, the analogy of `ld.so.conf' would be something along
> the lines of what you originally proposed[0]: storing the initial value
> of `%load-path' somewhere in a file (or bunch of file -- the `init.d'
> approach[1]), instead of having it hard-wired.

Yes, exactly.  The difference is which packages the information is
associated with.

Suppose you have an application foo which uses guile-gnome and
guile-pg.  guile-gnome is installed under /opt/gnome; foo and guile-pg
are installed under /usr/local; guile is in /usr.

Under previous proposals, there would have been config (under /etc)
associating:

  guile-gnome ... /opt/gnome/share/guile
  guile-pg ...... /usr/local/share/guile

and nothing for "foo" because it is an application, not a library.

Under this proposal, the config would be:

  foo ........... /opt/gnome/share/guile, /usr/local/share/guile

> The `init.d' approach was ruled out because of the increased startup
> time[2].  However, the single file approach had been considered
> unpractical because it is harder to add/remove directories from there,
> and to keep track of which packages exactly relied on it[1].

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.

I think this factor is the stumbling block.  As I type this, however,
I can also think of some objections to it:

1. A minimal load path is not really a minimal environment, because
   there can be other Guile packages installed under that load path's
   components which the application does not use.

2. The idea of a minimal environment is somewhat contrary to the idea
   of experimentation, and users being able to combine available
   modules in ways that the application developer might not have
   thought of.

3. There's one particular application, called "guile" (used
   interactively), where we really would like all installed packages
   to be available, even though they are not dependencies. :-)

4. Running with a non-minimal load path probably doesn't incur any
   significant runtime overhead.

Therefore, if no one else shares this neatness concern, I'm happy to
drop it... which then opens the door for your following suggestions.

> So, what if we just went ahead with the `init.d' approach, except that
> each file would only contain a single Scheme string?  This constraint is
> critical to address the startup time concern.
>
> 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")
>    ... )

I think this would be my preference.

> I'm sorry for getting back to this kind of proposal, but I think I'm
> getting confused.  Since the discussion spanned over several months,
> summarizing the key arguments seems important at this point.

No need to apologize; you're quite right that summarizing is useful.

I'd still like to hear a little more feedback about my latest idea
above, in case someone else can see compelling pros or cons in it that
I haven't identified yet.  But overall it looks like we are almost
settled on the single init file solution.

Regards,
        Neil