Ikarus should have an IKARUS_LIBRARY_PATH

Bug #163681 reported by Abdulaziz Ghuloum on 2007-11-18
2
Affects Status Importance Assigned to Milestone
Ikarus Scheme
Medium
Abdulaziz Ghuloum

Bug Description

Ikarus should have an IKARUS_LIBRARY_PATH from which libraries are looked up.
So, if the system tries to locate library (foo), it should look for the following in order:
  1. "./foo.ss"
  2. "P/foo.ss" for each P in IKARUS_LIBRARY_PATH
  3. $pkglibdir/foo.ss
Failing all of these, the system should raise an exception with a condition object containing the list of all searched locations.

Changed in ikarus:
importance: Undecided → Wishlist
Changed in ikarus:
assignee: nobody → aghuloum
status: New → Confirmed
Abdulaziz Ghuloum (aghuloum) wrote :

Added in revision 1090.

Changed in ikarus:
status: Confirmed → Fix Committed
Abdulaziz Ghuloum (aghuloum) wrote :

This bug report is about to be closed as the fix comitted previously
will be incorporated in the next 0.0.2 release of Ikarus Scheme,
scheduled for November 28, 2007.
A release candidate tarball is available for download from:
  http://www.cs.indiana.edu/~aghuloum/ikarus/ikarus-0.0.2-rc1.tar.gz
Please do test it if you have the time and report any issues you
might encounter. Thank you very much for your support. Aziz,,,
(Sorry for the duplicates; I'm updating every open bug.)

Changed in ikarus:
milestone: none → 0.0.2
Michael D. Adams (mdmkolbe) wrote :

The documentation for IKARUS_LIBRARY_PATH should mention that it is searched *in addition* to /usr/local/lib/ikarus. Also mention should be made that the local directory is searched in addition to IKARUS_LIBRARY_PATH and /usr/local/lib/ikarus.

One possible solution would be to just take something like the original bug description and add it to the "Contributed Libraries" section just before "Library Files" and "Defining IKARUS_LIBRARY_PATH".

Changed in ikarus:
status: Fix Committed → Confirmed
Abdulaziz Ghuloum (aghuloum) wrote :

documented

Changed in ikarus:
status: Confirmed → Fix Committed
Abdulaziz Ghuloum (aghuloum) wrote :

The way I have it right now is that IKARUS_LIBRARY_PATH replaces $pkglibdir, so if you want to search $pkglibdir, you should explicitly add it. Is that reasonable?

Changed in ikarus:
status: Fix Committed → Confirmed
Abdulaziz Ghuloum (aghuloum) wrote :

Okay, I was confused. You're right. Now, it appends. But I think it should be as follows:
If you don't have IKARUS_LIBRARY_PATH setup, it assumes ".:$pkglibdir"
If you do have it set up, then whatever you set up will be used instead.
What do you think?

Michael D. Adams (mdmkolbe) wrote :

Documented where? (I'm looking at revno 1140 which is the lastest from http://www.cs.indiana.edu/%7Eaghuloum/ikarus.dev/)

Specifically, Section 4, "Contributed Libraries", documents IKARUS_LIBRARY_PATH and /usr/local/lib/ikarus, but documents neither the relationship between the two nor the current working directory. Section 1.7, "Mapping library names to file names", documents does document the current working directory and the relationship between it and the "library directory", but also doesn't document the relationship between /usr/local/lib/ikarus and IKARUS_LIBRARY_PATH (and is a bit misleading in that it makes it sound like there is a single library directory). Both sections should reference all three locations and the order between them.

Michael D. Adams (mdmkolbe) wrote :

Heh, I guess it took me more then 11 min to compose my last reply. On the question of whether setting IKARUS_LIBRARY_PATH should cause ikarus to *not* search the current working directory or $pkglibdir, I'm not entirely certain. The convention I would naturally assume would be that IKARUS_LIBRARY_PATH is in addition to the current working directory and $pkglibdir (give me an hour and I should be able to check example of other programs), but there does need to be some way to override $pkglibdir (and maybe the current working directory).

Come to think of it, there may need to be a fourth location, the directory of the scheme script.

$ ls
test.ss
foo.ss
$ cat test.ss
(import (rnrs) (foo))
(display "ok")
$ scheme-script test.ss
ok
$ cd ..
$ scheme-script test/test.ss
Error: Can't find library "test".

Abdulaziz Ghuloum (aghuloum) wrote :

I think we should just ship it and retarget this for 0.0.3.

Michael D. Adams (mdmkolbe) wrote :

If you want to retarget for 0.0.3 that is fine by me as long as the actual behavior is documented (perhaps with a note indicating that it may change soon).

As far as untimate design, there seems to be very little consistency among languages (Perl, Python, Linux, Emacs, GHC) as to how they handle search paths (summary for the record at the end of this comment), so I guess we just have to choose based on design rather than convention. As a strawman I propose the following:

* If IKARUS_LIBRARY_PATH is not set, search script dir and $pkglibdir.
* If IKARUS_LIBRARY_PATH is set, search script dir and IKARUS_LIBRARY_PATH.
* IKARUS_LIBRARY_PATH may contain "." to reference the current working directory.
* IKARUS_LIBRARY_PATH may contain an empty string to indicate the default $pkglibdir (e.g IKARUS_LIBRARY_PATH='~/override::~/fallback' searches the script dir, then ~/override, then $pkdlibdir, then ~/fallback).

I still haven't figured out what to do about overriding the script dir. It is definitely needed as some scripts may get installed to places like /usr/bin and really shouldn't be looking in /usr/bin for their libraries. A flag could be added, but what if someone just wanted to add a directory to search before the script dir. Allowing something similar to "." to represent the script dir in IKARUS_LIBRARY_PATH poses difficulty as just about any keyword we choose may be an actual directory name.

Locations: PERLLIB, $pkglibdir
Overrides: No
Editable from inside: @INC
Deaults removable: No
Add pwd with "." to PERLLIB
Can't add script dir to PERLLIB.

Python:
Locations: script dir, PYTHONPATH, $pkglibdir
Overrides: No
Editable from inside: sys.path
Defaults removable: No
Add pwd with "." to PYTHONPATH

Emacs:
Locations: EMACSLOADPATH if set, $pkglibdir otherwise
Overrides: Yes
Editable fro inside: load-path
Defaults: removable: Yes (set EMACSLOADPATH)
Add pwd with "." to EMACSLOADPATH
Add script dir: Unknown

Linux:
Locations: LD_LIBRARY_PATH, $libdir
Overrides: No
Editiable from inside: N/A
Remove defaults: Unknown
Add pwd to PATH: N/A
Add swd to PATH: N/A

Michael D. Adams (mdmkolbe) wrote :

The documentation as updated in revno 1142 looks good.

Abdulaziz Ghuloum (aghuloum) wrote :

Retargetting to 0.0.3 and bumping importance. Thanks for reviewing the documentation.

Changed in ikarus:
importance: Wishlist → Medium
milestone: 0.0.2 → 0.0.3
Abdulaziz Ghuloum (aghuloum) wrote :

It seems like there isn't much that has changed here. Maybe the current behavior is "good enough" and not worth a change at this point. Should this be closed?

Abdulaziz Ghuloum (aghuloum) wrote :

This bug report is about to be closed as the fix comitted
previously will be incorporated in the next 0.0.3 release of
Ikarus Scheme, scheduled for January 31, 2008. A release
candidate tarball is available for download from:
http://www.cs.indiana.edu/~aghuloum/ikarus/ikarus-0.0.3-rc1.tar.gz
Please do test it if you have the time and report any issues
you might encounter. Thank you very much for your support.
(Sorry for the duplicates; I'm updating every open bug.)

Changed in ikarus:
status: Confirmed → Fix Committed
Changed in ikarus:
status: Fix Committed → Fix Released

Geoffrey,

Thanks for taking the time to maintain the ikarus package for Arch.

As for standard location for 3rd-party libraries, it seems that there
is not much agreement between different languages/implementations/
OSes. It's not clear to me what the right thing is.

The current situation is:

If IKARUS_LIBRARY_PATH is not set, Ikarus looks for libraries in
$pkglibdir (set during configure) and in the current directory.
Standard installation from source means: look in "." followed by "/
usr/local/lib/ikarus".
If IKARUS_LIBRARY_PATH is set to say "foo:bar", its elements are
added to the path yielding ".", "foo", "bar", "/usr/local/lib/
ikarus". This may not be documented properly and may not be the
right thing to do. See https://bugs.launchpad.net/ikarus/+bug/
163681 for more on this discussion (reopen the bug if needed).

So, why don't your 3rd-party libraries just go to the $pkglibdir
directly? That way, you don't have to mess with the library path at
all. The library path is meant to be set by the user to direct
ikarus to use libraries installed in nonstandard locations (home
directory, project directory, etc.). A system-wide standard location
should be specified by other mechanism (e.g., using configure), not
using the IKARUS_LIBRARY_PATH.

I don't know the reason for why perl/python have a site-perl/site-
python. How do the libraries in site-* differ from other libraries?

I also don't know what the debian convention is.

Aziz,,,

On Feb 16, 2008, at 2:30 AM, Geoffrey Teale wrote:

> Hi,
>
> Now that Ikarus is packaged for at least two Linux distributions I
> thought I might ask this question and see what the Debian guy
> (sorry forget his name) and the rest of you think.
>
> In order to support the packaging of third party libraries for
> Ikarus we need (presumably in the Ikarus package itself) to define
> a location for the third party libraries and to set the
> IKARUS_LIBRARY_PATH variable to point to this location. With that
> in mind the latest revision of my package for Arch Linux creates
> the directory:
>
> /usr/lib/ikarus/site-scheme
>
> .. and sets the IKARUS_LIBRARY_PATH in the global profile to:
>
> /usr/lib/ikarus:/usr/lib/ikarus/site-scheme
>
> I've followed the model used by GNU Emacs and Python (to name but
> two). So the questions are do people like that location (I'm open
> to better suggestions) and what is the Debian packager doing?
> Though we have an environment variable I think its nice for people
> using a language to be able to predict where their libraries are
> installed.
>
> --
> Geoff Teale
> <email address hidden>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers