Re: Modified load-path proposal

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> Neil Jerram <address@hidden> writes:
>
>> Sorry to have been carrying on this discussion for so long, and for
>> changing direction a couple of times.  If anyone is still reading, I'd
>> appreciate hearing your thoughts (again).
>
> Just a quick note to say:
>
> 0. I'm still reading.  ;-)

Thanks.

> 1. Your `init.d' approach looks very promising and simpler than the one
>    before, which is good.
>
> 2. I'd let the files in the `init.d' directory do a
>    `(require-load-path-directory ...)' rather than just containing the
>    directory name.  A good reason for this is that it is anyway very
>    easy to evaluate those files in a confined environment
>    (e.g. `null-environment' + the `require-load-path-directory'
>    binding).

OK, but aren't (1) and (2) both a bit scuppered by ...

> 3. I'm a bit concerned that this approach is not scalable: opening,
>    reading, and evaluating say a dozen of files each time Guile is
>    started may have a noticeable impact on startup time.

I think you're right.  It makes sense to do something like this for a
long-lived program such as Emacs, or for programs whose interactive
performance is not a concern, such as ifup and cron.  But we'd like
(or at least I'd like) Guile to be used for even very quick scripts,
and it doesn't make sense to increase the start up time of such
scripts by unconditionally loading arbitrary startup code for whatever
other Guile packages are installed.

I think this rules out any kind of iteration through a .d directory
from init.scm.  Apologies for not seeing this consideration before.

>    Maybe those could be loaded lazily, for instance in
>    `try-module-autoload', the first time `%search-load-path' fails.

This would be OK if the package startup file contained only a load
path, and not arbitrary code.  If the startup file was allowed to
contain arbitrary code, that code would presumably be important for
the initialization of the package concerned.  But it would be skipped
if some other circumstance meant that the package's install location
was already in Guile's load path.

Therefore any load-failure-based mechanism for loading startup files
needs to restrict the format of the startup files to just load path
directories.  It also has two disadvantages in my opinion.  Firstly it
feels a bit magic/under the covers/non-deterministic, where I would
prefer something more explicit/deterministic.  Secondly it still has
to unnecessarily load the startup files of all Guile packages on the
system, because it has no way to map the file name or module that
couldn't be loaded to a particular package.

So here's yet another proposal.  We keep the idea of a package
installing a startup file in some directory under $sysconfdir, but we
don't do anything with these in init.scm.  We provide instead:

 -- Scheme Procedure: initialize-packages . package-names
     Load the startup file for each of the packages in PACKAGE-NAMES.
     The startup file for a given package is only loaded once per
     Guile run, so `initialize-packages' avoids loading a package's
     startup file again if it has already been loaded.
     If one of the named packages doesn't have a startup file,
     `initialize-packages' calls `package-startup-file-not-found'
     with the package name as the only argument.  By default
     `package-startup-file-not-found' prints a warning to standard
     output, but you can `set!' it to something else if that is
     more appropriate for your application.

The idea would be for both Guile applications and Guile modules to use
this.  A Guile application should know which packages it uses
(directly), and so can include an appropriate `initialize-packages'
call in its startup script.  Similarly a Guile module knows which
packages it uses, and so can call `initialize-packages' before trying
to use any modules from that package.

(In practice this would mean before the define-module form, but I
don't see anything wrong with that.  For example:

  (initialize-packages "guile-gtk")

  (define-module (ossau widgets)
    #:use-module (gtk gtk)
    ...)

)

I believe this scheme works equally well whether we allow the startup
file to contain arbitrary code, or we restrict it to contain just load
path directories.  If we chose to restrict it, we might want to rename
`initialize-packages' to something more precise, such as
`merge-package-load-paths'.

A possible benefit of the restricted format is that I think we could
write an autoconf macro (for configure.in) that would generate and
install the startup file completely automatically.  But perhaps we can
still do that anyway with the arbitrary code format, and allow it to
be overridden when the package has particular requirements.

So (once again!) please let me know your thoughts.  Is this at last
the answer?

Regards,
        Neil