Re: Managing Guile and extensions versions

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi Vorfeed,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> 4. Actual contents of default directory list is not important. Only
> two requirements:
>   A. It must not be empty  - this way there are place to put default
> libraries like readline.
>   B. It must be modifyable at runtime - this way complex program (like
> Gnumeric or
>       Gnucash) can keep it's private libraries private and not pollute
> default directory.

Right.

> In short: do not bother too much with understanding of my default
> locations choice.

Sure.

So, I'm all in favor of having your patch (or something equivalent)
applied.  I guess you'll need to /kindly/ ask the developers for further
reviewing and see what needs to be done so that it can actually be
applied.

> I did so as well, but surprisingly it's VERY minor issue: since it's
> determined by GUILE_SITE_DIR and then by guile-config you can change
> this default quite easily WITHOUT changing third-part extensions code!

This is true since `GUILE_SITE_DIR' is already widely used.  In fact,
the right way to do it would probably be to have:

1.  `%site-dir' (and obviously `GUILE_SITE_DIR') return
    `${datadir}/guile/MAJOR.MINOR/site';

2.  `%load-path' include both `${datadir}/guile/MAJOR.MINOR/site' _and_
    `${datadir}/guile/site' (in this order).

> Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD
> sample: university system where you can only install stuff in your own
> home directory.

Yes you can: have third-party C libraries use Guile's version info.
IOW, add `-version-info
$LIBGUILE_INTERFACE_CURRENT:$LIBGUILE_INTERFACE_REVISION:$LIBGUILE_INTERFACE_AGE'
to your LDFLAGS.

However, this would not permit extension developers to use
`-version-info' for their own versioning purposes, so it sucks.

> Yes, it'd be quite nice to allow both (1) and (2). But!
> 1. It'll require major redesign or libtool (actual shared library is
> versioned, but .la file is not).

I don't think so but that discussion belongs to `libtool@'.

> 2. Crude yet effective substitute usually enough: just add something
> like "v2" to name of extension (like glib vs glib2). Not elegant but
> it works...

Remember: that's what `libguile-readline' already does.  You might want
to re-read your email answer to my suggesting such workarounds.  :-)

> In fact I'm not even sure this problem need solution! Think about it:
> if we'll allow this we should allow two version of, for example (web
> serialize) module. This means we'll be forced to develop some
> versioning for scheme modules as well. A lot of work for unknown
> benefit: in RARE cases where you really need two versions of the same
> module you can cope with %load-path/%load-libpath tricks.

"Lack of vision" you said earlier, right?

I believe Scheme module versioning would be beneficial, although I have
lived without it so far.  Anyway, a quite straightforward solution (at
first sight, at least) would be something like:

  (define-module (my-module)
    #:version/current 2
    #:version/age 1
    #:version/revision 4)

And:

  (use-modules ((my-module) #:interface 1))

This would look for `my-module.scm' in the directories of `%load-path'
and only import bindings from the first one (for instance) that
implements version 1 of the interface, in pure Libtool style.  And
AFAICS, this wouldn't introduce any compatibility issue: both versioned
and unversioned modules and module users could peacefully coexist.

That may add some overhead in the rare case where a significant number
of different versions of a module are available, since Guile needs to
load each module before knowing whether it matches the constraint.

Hmm...  In fact, that may be much more complicated than it seems since
`resolve-module' relies on `nested-ref' to find a module, and since
there can only be one module bound to a given name...

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user