Trying to fix propagated-inputs in Guix for Guile libraries

[Vivien Kraus via General Guile related discussions <guile-user@gnu.org>]

Dear guile users,

I am thinking about how to avoid using propagated inputs with guile
modules. In Guix, we may have different incompatible versions of a
library. It might not be the case right now (are all guile-json
versions really incompatible?), but we may be able to avoid some
trouble in the future if we’re prepared.

For C code, the solution is to make shared objects, and use the rpath
option in each linked object to know where to find its dependencies (
https://en.wikipedia.org/wiki/Rpath).

The fact that this behavior works for C lets me wonder why there’s no
such thing in guile. Is it because, as it is a live environment, users
are supposed to know better what library to use?

In any case, if I wanted to have something like rpath in guile, I would
want to do something like:

(define-module (foo)
  #:use-module ((dependency) #:from "/gnu/store/xxx-dependency-
1.0/share/guile/site/3.0"))

However, the path is only known after the configure step, so it’s not a
good thing to write it down in the source code. So, we would only write
it down in the bytecode, with a new compiler switch.

The next question is, what to do with the source code? Would it be OK
to have a different behavior for uncompiled source? After all, since
it’s not compiled, configure has not run so there is no reason to think
that the library author could find better dependencies than the user.
Or, could we decide not to install source code (.scm) when installing a
library, and only install .go files? Does guile even works if there’s
no corresponding source code for a compiled module?

Vivien