SISC

after glancing at provide-library inside the brief file
"sisc/src/sisc/modules/libraries.scm", another dirty workaround would be

-use require-library once to get the library name registered centrally and
have the out of date library loaded
-use load with explicit path to correct library file.

i'm not sure if you are also using modules inside the files. but possibly,
if you only needed to override the library and not reloaded it multiple
times, you could perform the import after the 2 steps above.

just my own feedback, i'm not weighing in on whether provide-library
should be exposed or if classpath manipulation should be enhanced.

-kanishka

Logged In: YES
user_id=590785

Apparently you misread my comment. require-library (and
implicitly req-ext) *don't see* some libraries (due to
classpath issues). In such cases (load) + (provide-library)
are the only substitute. For this reason alone (and not to
parallel SRFI-55) please document provide-library.

What classpath issues, specifically?

1) Situations where the class path already contains an older
version of the library. Since there is no
classpath-ext-PREPEND, the old lib always wins.

2) Situations where (class-path-ext-append) is ignored. I'm
not sure why, but I've seen that happen.

3) Situations where I do not want to "pollute" the classpath
(since there's no classpath-ext-UNAPPEND, such pollution
cannot be cleaned up)

Logged In: YES
user_id=25869

SRFI-55 is supported, and is probably a better (more
standard) way to expose that functionality.