Re: The last piece in parallel-install

[Greg Troxel]

  Priorities: conciseness, from the point of view of application code,
  clarity of semantics, and Just Works(tm) foo.

I concur.

  Greg suggested that the module be named (gnome gnome-N), where N is a
  version. I think this is suboptimal because it requires that there be
  two directories in the load path that have a gnome/ subdirectory, which
  could lead to ambiguities. (One for the standard load path, to get the
  versioning module, and one that actually has the code.) Just (gnome-N)
  is a better idea I think.

By ambiguity, I think you mean a use-modules invocation that will
return different results depending on %load-path ordering.  Since
(gnome gnome-0) is gnome/gnome-0.scm, and there is no gnome-[0-9]*.scm
in the per-module gnome/ dir, this is actually ok.  But I see your
point that it could be or later become confusing.

Just (gnome-n) is fine; the actual number installed at any time is
unlikely to be more than three, even if guile-gnome achieves World
Domination.  So the gnome-turds level in the standard path will be
small, and they'll sort near each other, so it won't annoy people.

  The fact that the
  module can be used at all indicates that it must be installed in a dir
  of the standard load path, regardless of what the user's prefix is. This
  also hacks around the default-inst-dir-not-in-the-default-load-path
  problem. 

This is combining two issues, about one of which we do not appear to
have consensus.  One is how a module installed in a prefix different
from guile is accessed.  The other is how module-version-specific
paths get added.  (With guile-gnome-0, the user has to put the
$prefix/bin dir in their PATH.)   The versioned libs are intentionally
put someplace that essentially cannot be in a normal load path, and
that's fine.
(BTW why are they in $prefix/share/guile-gnome-0, instead of
$prefix/share/guile/guile-gnome-0?  Is that to keep them from being
invoked as (guile-gnome-0 gnome glib), which would be a mess?
Actually that seems like a very good reason.)
So putting gnome-n  in the standard place (site or not :) in guile-gnome's
prefix solves the version issue, leaving the different-prefix issue
to be solved.  Whatever solves that will work with the version plan,
so it's not necessary to have a joint solution 

  Now, the semantics: What actually happens when I (use-modules
  (gnome-0))? Since (gnome-0) is tied to a particular installation of
  guile-gnome, it knows where to find the modules, so it can push the
  guile-gnome-0 load path directly (without searching like pygtk does).

Sounds good - just modify %load-path so that a (use-modules (gnome glib))
will work.

  It
  can also munge the LD_LIBRARY_PATH with getenv and setenv, so that the
  libs are found. Which means, it subsumes all of the functionality of the
  guile-gnome-0 script!

I view this as only a workaround until the scheme code is fixed to
load things from the right place.  In general as we get more
complexity adding searching rather than 'look in the right place'
seems to be asking for trouble, and thus searching should be avoided
when the right place can be programmatically known (which it can for
the libs).

  I thought about having just (gnome), which would export a procedure to
  choose the version, but such a module won't allow for parallel
  installation of different versions in different prefixes. This could be

I concur that this isn't really a good idea.
And I don't think it is needed.  If someone rights code against the
API for guile-gnome-0, they won't be bothered to have

(use-modules (gnome-0))

in their program to declare this.
Perhaps gnome-n can use some variable (in the (gnome) module?) as a
flag that gnome-n has been used for some value of n, and error out if
a different version is tried.  Essentially:

(define-module (gnome))
; check if gnome-version is bound
; if not, set to 0
; if yes, error out if not 0
; augment load path

-- 
        Greg Troxel <address@hidden>